Re: filterMap, for comprehensions and collection-oriented functions

For what it's worth, I just did a day's worth of 
filter/map/uniq/sort/map coding (in Ruby, sadly)

I would have loved to have a construct like this... it would have cut 
10% off the amount of code I wrote.

Judson, Ross wrote:
> I've had repeated occasion lately to filter lists so they match a
> pattern, then act on the results.
> Given:
>
> trait Item {
>   type T
>   val value: T
> }
>
> class StringItem(value: String) extends Item {
>   type T = String
>   def lower = value.toLowerCase
> }
> class IntItem(value: Int) extends Item {
>   type T = Int
> }
>
> val items = List[Item](...)
>
> With the latest scalac I can filter down to the StringItems very
> cleanly:
>
> for (val si  <at>  StringItem(_) <- items) { println(si) }

targeting older JVMs?

hi,

Bruce Eckel's complaints about Java
http://www.artima.com/forums/flat.jsp?forum=106&thread=193593 make me
think that I'd like to use a language like Scala so I can get advanced
programming constructs, but have it target older (e.g. 1.4 or even
1.3) JVMs / JREs for the bytecode. That would seem to get around some
of the "oh you have to first upgrade your Java install" problems. But,
last I tried, I think Scala wanted 1.5?

Lazy evaluation

What can I do to get lazy evaluation below? The code produces a stack
overflow, when it needn't use so much stack for its computation.

sealed abstract class List[+A]
private case object Nil extends List[Nothing]
private final case class Cons[+A](head: A, tail: List[A]) extends List[A]

object List {
  def repeat[A](a: => A): List[A] = {
    Cons(a, repeat(a))
  }

  def head[A](xs: => List[A]): A = xs match {
    case Nil => error("empty list")
    case Cons(x, _) => x
  }

  def empty[A]: List[A] = Nil

  def ::[A] (x: A)(xs: => List[A]): List[A] = {
    Cons(x, xs)
  }
}

object Main extends Application {
  import List._

  def x: List[Int] = ::(1)(::(2)(::(3)(empty))) // [1,2,3]
  def y: List[Int] = repeat(7)
  def z = head(y)

Re: Lazy evaluation

Tony Morris wrote:
> What can I do to get lazy evaluation below? The code produces a stack
> overflow, when it needn't use so much stack for its computation.
> 
> sealed abstract class List[+A]
> private case object Nil extends List[Nothing]
> private final case class Cons[+A](head: A, tail: List[A]) extends List[A]
> 
> object List {
>   def repeat[A](a: => A): List[A] = {
>     Cons(a, repeat(a))
>   }
> 
>   def head[A](xs: => List[A]): A = xs match {
>     case Nil => error("empty list")
>     case Cons(x, _) => x
>   }
> 
>   def empty[A]: List[A] = Nil
> 
>   def ::[A] (x: A)(xs: => List[A]): List[A] = {
>     Cons(x, xs)
>   }
> }
> 
> object Main extends Application {
>   import List._
> 
>   def x: List[Int] = ::(1)(::(2)(::(3)(empty))) // [1,2,3]
>   def y: List[Int] = repeat(7)

Re: Lazy evaluation

Eric Willigers wrote:
> Tony Morris wrote:
>> What can I do to get lazy evaluation below? The code produces a stack
>> overflow, when it needn't use so much stack for its computation.
>>
>> sealed abstract class List[+A]
>> private case object Nil extends List[Nothing]
>> private final case class Cons[+A](head: A, tail: List[A]) extends List[A]
>>
>> object List {
>>   def repeat[A](a: => A): List[A] = {
>>     Cons(a, repeat(a))
>>   }
>>
>>   def head[A](xs: => List[A]): A = xs match {
>>     case Nil => error("empty list")
>>     case Cons(x, _) => x
>>   }
>>
>>   def empty[A]: List[A] = Nil
>>
>>   def ::[A] (x: A)(xs: => List[A]): List[A] = {
>>     Cons(x, xs)
>>   }
>> }
>>
>> object Main extends Application {
>>   import List._
>>
>>   def x: List[Int] = ::(1)(::(2)(::(3)(empty))) // [1,2,3]

Re: Lazy evaluation

Re: targeting older JVMs?

Raoul Duke wrote:
> hi,
> 
> Bruce Eckel's complaints about Java
> http://www.artima.com/forums/flat.jsp?forum=106&thread=193593 make me
> think that I'd like to use a language like Scala so I can get advanced
> programming constructs, but have it target older (e.g. 1.4 or even
> 1.3) JVMs / JREs for the bytecode. That would seem to get around some
> of the "oh you have to first upgrade your Java install" problems. But,
> last I tried, I think Scala wanted 1.5?

Scala should work on Java 1.4. You can target jvm 1.4 like this:

scalac -target:jvm-1.4 <sources>

The default should be 1.4, so I am surprised you say it was different
for you.

Iulian
PS. The Scala Eclipse plugin requires Java 1.5 indeed, but programs
compiled with the plugin should run on 1.4.

Re: targeting older JVMs?

Taken from the Scala website:

  "The Scala software requires version 1.4 or later
   of the Java 2 Runtime Environment."

  [http://www.scala-lang.org/downloads/]

And also:

  "[...]
    –target: <target>
       Specify which backend to use (jvm-1.5,jvm-1.4,msil,cldc).
       The default value is "jvm-1.4"."

  [http://www.scala-lang.org/docu/files/tools/scalac.html]

Bye
--Stephane

Raoul Duke wrote:
> hi,
> 
> Bruce Eckel's complaints about Java
> http://www.artima.com/forums/flat.jsp?forum=106&thread=193593 make me
> think that I'd like to use a language like Scala so I can get advanced
> programming constructs, but have it target older (e.g. 1.4 or even
> 1.3) JVMs / JREs for the bytecode. That would seem to get around some
> of the "oh you have to first upgrade your Java install" problems. But,
> last I tried, I think Scala wanted 1.5?

Re: Lazy evaluation

Burak Emir wrote:
> 
> 
>     Thanks Eric,
>     I tried what you suggest earlier, but it failed to compile:
> 
>     error: `val' parameters may not be call-by-name
>     private final case class Cons[+A](head: A, tail: => List[A]) extends
>     List[A]
> 
>     *Must* I add a body to my case-class/data constructor? What am I
>     missing?
> 
> 
> Tony, the trouble is that tail becomes a val of the class... and the 
> compiler does not like that. To work around it, you would need to take 
> an argument that is Function0[List[A]] or Function1[Unit, List[A]] or 
> something like that.
> 
> This is likely not what you want for the constructor, but there is a way 
> out. Lex changed the Stream class recently to use unapply patterns for 
> matching. See what it does with the def parameter to circumvent that 
> problem
>
http://scalasvn.epfl.ch/cgi-bin/viewvc.cgi/scala/trunk/src/library/scala/Stream.scala?view=markup 

Hi Burak,

Very informative.

Using the design in this thread it takes a while to achieve requirements 
like
(a) the tail not being evaluated more than once
(b) the tail not being evaluated when returning head

The code below compiles with 2.3.3 and achieves both (a) and (b).

Making head and tail abstract functions of List, as in the standard 
design, would have been simpler but we would have learnt less.

Regards,
Eric.

sealed abstract class List[+A]
private case object Nil extends List[Nothing]

private final case class Cons[A](head: A, var tailThunk: () => List[A]) 
extends List[A]
{
     var tailEvaluated = false
     var tailValue: List[A] = _

     def tail: List[A] =
     {
         if (!tailEvaluated)
         {
             tailValue = tailThunk()
             tailEvaluated = true
             tailThunk = { () => tailValue }
         }
         tailValue
     }
}

private object Evaluate
{
     def unapply[A](xs: Cons[A]): Some[Cons[A]] =
     {
         xs.tail
         Some(xs)
     }
}

object List {
     def repeat[A](a: => A): List[A] = {
         Cons(a, () => repeat(a))
     }

     def head[A](xs: => List[A]): A = xs match {
         case Nil => error("empty list")
         case Cons(h, _) => h
     }

/* // leads to tail being evaluated more than once
     def tail[A](xs: => List[A]): List[A] = xs match {
         case Nil => error("empty list")
         case Cons(_, t) => t()
     }
*/

     def tail[A](xs: => List[A]): List[A] = xs match {
         case Nil => error("empty list")
         case Evaluate(Cons(_, t)) => t()
     }

     def empty[A]: List[A] = Nil

     def ::[A] (x: A)(xs: => List[A]): List[A] = {
         Cons(x, () => xs)
     }
}

object Main extends Application {
     import List._

     def x: List[Int] = ::(1)(::(2)(::(3)(empty))) // [1,2,3]
     def y: List[Int] = repeat(7)

     var hasBeenCalled = false
     def onceOnly: List[Int] =
     {
         if (hasBeenCalled)
         {
             error("already called")
         }
         else
         {
             hasBeenCalled = true
             ::(29)(empty)
         }
     }
     val z: List[Int] = ::(14)(onceOnly)

     Console.println(head(x))
     Console.println(tail(x))

     Console.println(head(y))
     Console.println(tail(y))

     Console.println(head(z))
     Console.println(head(z))
     Console.println(tail(z))
     Console.println(tail(z))  // This fails when using the commented 
out tail

     Console.println( head(::(1)(error("evaluated tail"))))
     Console.println( tail(::(1)(::(2)(error("evaluated tail")))))
}

Re: Scala paper: Actors that Unify Threads and Events

David,

> Does there exist any sample code for using JXTA for transport between
> Scala Actors?

In fact, a few months back Sebastien Noir had been working on a JXTA
transport layer for remote actors. We even had a small auction service
application running (complete with GUI!). Unfortunately, I never got
around to refactor the code to work with the re-designed actor library
(there were also changes in the "remote" part). I still have a fully
working copy of that on my machine.

So, actually, it would be a great contribution if you (or someone else
on the list) would take the code and integrate it with the new actors
library! I would provide assistance where needed, of course.

This would indeed be a great service to the community and make remote
actors much more valuable.

Cheers,
   Philipp

> 
> Thanks,
> 
> David
> 
> PS -- The more time I spend with Actors, the more I like them.  Thanks
> for doing a rockin' job on them!
> On Jan 30, 2007, at 5:46 AM, Philipp Haller wrote:
> 
>> Terrance Sullivan wrote:
>>> As I recall from reading Philipp's early paper and the sense Erlang  the
>>> language may have also possibly influenced his work on Scala  Actors
>>
>> Indeed, Scala's actors were influenced to a large extent by Erlang.
>>
>>> (?), would suggest taking a look at YAWS (Yet Another Web  Server) done
>>> in an Erlang/Actor style with interesting performance  and robustness
>>> characteristics or YXA which is a similarly  implemented instance of
>>> SIP. Certainly, the 15+ years Ericsson has  acquired using Erlang/OTP on
>>> their production ATM switches would also  suggest that this is a well
>>> founded technique.. Equally one could  back track to some of the
>>> material at the Erlang.org site..
>>
>> I agree. Existing Erlang work might be very helpful to look at. After
>> all, the programming models are very similar. I also recommend the
>> Erlang book ("Concurrent Programming in Erlang", 2nd ed. by Joe
>> Armstrong et al.). It contains a wealth of programming examples for
>> actor-style message passing concurrency. Most of them should be
>> straight-forward to write using Scala actors.
>>
>> On the other hand, I fully agree with Warren that a comprehensive
>> example in Scala would be a very good thing.
>>
>> Actually, some larger programs have been developed in our lab.
>> Unfortunately, they have to be re-written since the actor library has
>> been re-designed in the meantime. I'll take a look and see how much work
>> it is to update the old code.
>>
>> Another point regarding "massive scalability". I think it is important
>> to note that large numbers of actors are not only interesting for
>> network applications such as web or Jabber servers (for connections/user
>> sessions).
>>
>> Lightweight actors are also crucial if you intend to build general
>> abstractions on top of them. As a rather radical example, imagine
>> replacing all your normal objects with actors...
>>
>> Cheers,
>>    Philipp
>>
>>
>>
>>> /Terry
>>>
>>> On 29-Jan-07, at 12:32 PM, Warren Henning wrote:
>>>
>>>> On 1/29/07, Philipp Haller <philipp.haller <at> epfl.ch> wrote:
>>>>
>>>>> Feedback is very welcome!
>>>>
>>>>
>>>> What would help me the most in understanding actors is a practical
>>>> example that clearly shows how the actor system can be used to create
>>>> real-world massively scalable systems. What would be nice is a
>>>> complete, realistic program, not too short but not too long, either,
>>>> that I can compile and run involving something, say, network-related,
>>>> that I can try out on my home machine and play around with.
>>>>
>>>> Apparently a tutorial of some kind is underway on the actors library
>>>> and I eagerly await it.
>>>>
>>>> Warren Henning
>>>>
>>>
>>
>>
> 
> -- 
> David Pollak
> http://blog.lostlake.org
> 
> 
> 
> 
>