Scala (Language)

Official Materials

• Scala website

Notes

On "An Overview of the Scala Programming Language" An Overview of the Scala Programming Language, Second Edition, by Martin Odersky et.al

• The point of Scala's pattern matching feature is not quite clear to me.

• Scala's "id: type" syntax is rather less easy to read than Java's "type id" syntax.

• The "optional semicolon" idea is very problematic, delimitation of statements should be unambiguous, and the significance of tokens (whether semicolon or newline) should be unambiguous as well. Interpreting newline as a statement terminator if a statement terminator makes sense here is an idea that has wrought havoc in R already.

• The "value oriented" interpretation of the == operator seems problematic to me. What should the Scala programmer use to test for object identity?

• Also, the interpretation of "x == y" as "x.==(y)" might result in an asymmetry (loss of commutativity) which may prove particularly problematic. I'd generally consider it a good idea to have a mechanism that just is commutative, rather than having to rely on adherence to some kind of contract to ensure commutativity where that is required.

• The idea that language features such as comprehensions can be built on top of any type providing the appropriate methods / implementing the appropriate interfaces is quite attractive. Kind of like Python, where it's possible to pass any object implementing the methods read or readline where "normally" a file would be passed in.

• Interesting hack to declare parameters of type T as "=> T" ("function returning T") to lazily evaluate parameters of that type.

• According the "op1.operator(op2) is equivalent to op1 operator op2" rule, "op1 operator" represents a unary function that takes the missing operand. Hmm... is that awkward or just something to get used to?

• It's interesting that Scala uniformly supports abstraction via parameterisation and via abstract members. Does this result in a potential "many ways to do a thing" curse, though?

• The nonvariant / covariant / contravariant system of Scala seems very interesting. Perhaps it solves some of the problems of Java generics... although these problems are mainly due to prioritising backward compatibiltiy too much...

• The path dependent type concept is not (yet?) clear to me ... paths of what kind???

• Seems like the requires clause is like extends, with the difference that the type being extended can be something like a trait or interface.

• Scala's behaviour to return the last computed value may be popular in functional programming communities, but it's nonetheless a problematic behaviour. Typing a keyword such as return, to express that this is the object to be returned, is not really asking too much.