http://forums.oracle.com/forums/thread.jspa?threadID=594269&tstart=15

-cwl

“class” definitions have to be instantiated, like in Java. “object” definitions are singletons (they only contain static members):

object SimpleGreeter {
private val greeting = “Hello, world!”
def greet = println(greeting)
}

SimpleGreeter.greet

Note that the parentheses after method calls are optional. By convention, Scala programmers write them if the method call has side effects, and leave them out otherwise (for example a getter has no parentheses).

In your example of “max”, the result type (Int) is explicitly mentioned, the example code should probably read:

def max(x: Int, y: Int) = if (x < y) y else x

Variable types of arguments have to be explicitly mentioned, because they cannot be “guessed” from the context.

Traits are like abstract classes or interfaces, with the exception that they have no constructors. This allows Scala to do multiple inheritance. Traits are described here: http://www.iam.unibe.ch/~scg/Research/Traits/

Thanks for the review! By the way, I was a student of Martin Odersky’s course of “Power Java”. One of our assignments was to write a simple LISP interpreter in Scala (with REPL). You might be interested:

http://lampwww.epfl.ch/teaching/archive/programmation_4/2007/exercises/project6/project6.pdf
http://lampwww.epfl.ch/teaching/archive/programmation_4/2007/exercises/project6/lisp-partial.scala

fun x y -> x + y has type int -> int -> int, curried;

fun (x, y) -> x + y has type int * int -> int, the single argument is a tuple, so this function can’t be curried.

Regarding purity, it depends on how we define it, of course. I believe that Odersky is well aware that ML is not “purely functional” in the sense of being “referentially transparent”, because it allows functions with “hidden” side-effects that aren’t transparent. But I don’t think ML was ever conceived as a multi-paradigm language (not the original ML, at least; OCaml is another matter). ML is primarily functional, with side-effects allowed for pragmatic reasons, but a side-effects-free programming style is preferred.

As for differences with python, there are many. I, and many others that have worked with scala for some time, think of it like a mix of Java and Haskell. Scala is statically-typed with type inference, favors a functional style, runs in the Java Virtual Machine and its type system would appear very strange for a python programming, I guess.

Also, these days it’s faster to make new objects and allow them to be efficiently GC’ed, than incur the GC overhead that results when you mutate an existing object (interesting point!).

What is the GC overhead from mutation? Perhaps you refer to the synchronization overhead? Apologies for the ignorant question.

Andy