Scala (Language)

From Jtkwiki
Jump to navigationJump to search

Official Materials


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

  • 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.