Philosophy: Happy blend of OO and functional programming paradigms, running atop the JVM.

History: started in 2003 by Martin Odersky of EPFL in Switzerland. Built out of the "Pizza" project by Odersky and Wadler.

In use: 
- Twitter (as of 2009) http://www.artima.com/scalazine/articles/twitter_on_scala.html
- LinkedIn (as of 2010) http://www.infoq.com/articles/linkedin-scala-jruby-voldemort
- FourSquare (as of 2009) https://groups.google.com/forum/#!topic/liftweb/Em5rHlKfvRQ (using the Lift web framework)

Our interest is the Actor pattern, which is modeled after Erlang. We will talk about 2.9 Actors; as of 2.10 they recommend using the Akka actors library, but there is little available documentation on this, so we'll stick with 2.9 Actors, and hopefully that will give a good enough idea of what's going on.

http://akka.io/

=========================================
====== Sequential Scala Tutorial (from the web page) ======

http://www.scala-lang.org/docu/files/ScalaTutorial.pdf
See also http://www.scala-lang.org/docu/files/ScalaByExample.pdf

HelloWorld.scala
  features
    Array[String] : type operator with post-fix instantiation, using []
    def: defines methods
    no semi-colons at the end of lines; EOL is sufficient
    object definition, rather than class definition (think of it as a singleton class)
    println, as in Java (no System.out required)
    no static methods (use singleton objects)

Interaction with Java: FrenchDate.scala
  features
    import java.lang by default
    import with curly braces for multiple classes
    use _ not *
    no type decls for local variables (uses local type inference)
      two kinds: var for mutable variables, and val for values
    no use of () for empty argument list (like Ruby)
    df format now == df.format(now)

Everything is an object
  1 + 2 == (1).+(2)
    parens arond the numbers force parsing of 1 and not 1. (which is short for 1.0)
  Functions are objects
    Timer.scala:  function types (uses => with Unit return type, but () argument type)
    TimerAnonymous.scala: Anonymous functions designated by =>
  Modified class hierarchy: UnifiedTypes.scala
    http://www.scala-lang.org/old/node/128
    scala.Any at the top; two below it
      AnyVal: all "values" which are predefined (int, float, long, etc.)
      AnyRef: same as java.lang.Object
        all user-defined classes implicitly extend *trait* scala.ScalaObject (which extends AnyRef)
	(a Trait is like a Java interface, see below)

Functional vs. OO style
  Sort.scala

Classes
  Complex.scala: 
    note two defs in one file (name doesn't matter)
    "parameters" in parens in definition; immutable
    don't annotate return type---will be inferred
      Can put :Type after to specify it if you want
    can drop () after def of method to not require () in calling the method
  Class hierarchy: scala.AnyRef is at the top
  Overiding is explicit with override keyword
    no "return" keyword---final expression is the result (like Ruby)

Case classes: encoding ML data types and pattern matching
  abstract supertype, case class for each variant
    case classes come with built-in equals(), hashcode(), and tostring() methods (by structure)
    can be pattern matched: t match { ... }
    automatic getter methods
    no use of new keyword (as with datatype constructors)
  PartialFunction[A,B] values
    Can be defined with syntax { case X => Y } where X has type A and Y has type B
      Used for environments in this example
  Pattern matching examples
    derive uses "guards" which must be pure functions (?)
    Also uses _ and standard stuff
  Do version without derive() function
  Show OO version
  Add derive() to the first
  Now add to the OO version

Traits: an alternative to inheritance for code sharing
  Ord.scala
    Like an abstract class, but you can "extend" many of them
    Note 
      the use of == actually directs to .equals() (reference equality is eq)
      the use of Any rather than Object (so it can include values)
      the use of .isInstanceOf[T] instead of instanceof
      the use of e.asInstanceOf[T] instead of (T)e
      the use of a non-standard method name < (and others)

Generics
  Note the use of
    variables starting with var (these are mutable, whereas parameters are immutable)
      Note the use of _ for the default value; which apparently is filled in based on T's eventually instantiation

Views (?)

Scala collections (cool to learn about?)

=========================================
====== Actors

http://docs.scala-lang.org/overviews/core/actors.html
Akka actors are similar
  Migration guide: 
  http://docs.scala-lang.org/overviews/core/actors-migration-guide.html

Defined in scala.actors package
  So can import actors._ to get everything

Like Erlang:
  Does not map actors to threads one-to-one
    When using "react" instead of "receive" for message receipt
      Implementations a "continuation closure"
    Uses Fork/Join as the underlying implementation
  Actors do not share state
  Actors have a mailbox for receiving messages (aka channel)
  Messages are immutable 
    Tend to use case classes

Reactor trait
  Super trait of all actor traits. Extending it allows you to send and receive messages.
  Type parameter Msg indicates the type of messages it sends
  method ! sends a message (i.e., a ! "foo" sends message "foo" to actor a)
  method react receives messages from the mailbox
    takes a PartialFunction[Msg,Unit] argument
    never returns (use exit)
  method act is the body of "spawn" in Erlang
    starts up in a separate thread when you call .start on the (re)actor (which also returns the reactor
      calling it a second time does nothing
  also has a "forward" method --- discussed later
  method actor is a factory method (takes the body that implements the act() method)

  Control structures
    andThen
    loop
    loopWhile(c) 
      can put continue in the body of either

  example: seq.scala
  example: looping.scala
    no main() method. Instead, can inline commands directly in the pingpong class, since it extends App
      These get turned into a de-facto main method
  example: pingpong.scala

  Notes
    Can restart it by calling restart (instead of start), but must be dead
    Can call getState to figure out its execution state: New, Runnable, Suspended, Terminated

ReplyReactor trait, extends Reactor[Any]
  overrides ! method to also send reactor reference
  method sender returns reference to sender of message being processed
  method reply is a shortcut for responding
  method !? is synchronous: returns first message that is sent back
    If given two parameters, one of them is a timeout (in ms)
  method reactWithin does timeouts 
    do reactWithin(X) { ... } instead of react { ... } can have case TIMEOUT

  Example: cas.erl and cas.scala
  Example: semaphore.erl and semaphore.scala
  Example: boundedbuffer.scala
    Aside: implicit ClassTag is to be able to coerce to types in get()

  method !! is like !? but (immediately) returns a Future
    if given two parameters, the second is a closure to post-process response, returned to future
    Example use of Futures
      val fut  = a !! msg
      val res = fut() // waits for the future
        OR
      fut.isSet checks whether it's been returned or not
    method future takes a code block and runs it asynchronously

Actor trait extends ReplyReactor
  method receive can return a result, but is more heavyweight (blocks thread waiting for result)
  link and unlink methods for fault tolerance (as per Erlang)
    trapExit method to react to failure of linked-to actor
  subclass DaemonActor will not prevent termination

Channels
  used to simplify the handling of messages that have different types but that are sent to the same actor. 
  OutputChannel trait
    out ! msg
    out forward msg
    out.receiver
    out.send(msg,from)
  InputChannel trait
    in.receive { } 
    in.react { }
      and versions Within
  Channel extnds both
    takes type parameter for messages
    can create and share them directly
    
  example: simplechannels.scala
  example: channels.scala

Schedulers
  Reactor trait scheduler : IScheduler
    trait has a execute() method
  Can make custom schedulers by extending SchedulerAdapter
    implement the execute(fun : => Unit) : Unit method to run jobs
    typically you'd use a thread pool
  SingleThreadedScheduler must be shut down manually
    
  example: message.scala

Remote Actors (like Erlang)
  no details!

=========================================
====== Parallel/concurrent Scala: Actors, Parallel libraries

http://docs.scala-lang.org/overviews/parallel-collections/overview.html

