thanks for your very good comment, that made me write my latest post: http://www.francolombardo.net/fantom-vs-scala-semicolon-inference-and-something-more_post-98.html

Concerning the semicolon inference issue I have specifically seen it come up in the context
of definition of domain specific languages (DSLs). Several Scala features can be used to define
such DSLs, specifically “Automatic Type-Dependent Closure Construction”, see :

http://www.scala-lang.org/node/138

The idea is very! appealing. However, there seems to be three problems
with this approach in Scala, which I would like to see comments on.

Problem 1 - “the eager semicolon”:
automated inference of semicolon causes DSL constructs to be only
partially parsed leaving the rest unparsed as a DSL construct

Problem 2 - “the satisfied semicolon”:
partially written (incomplete) DSL constructs are accepted

Problem 3 - “the lazy semicolon”:
one has to write a semilon to end a call of a method that takes () as argument,
otherwise the Scala parser will complain about subsequent text as supurfluous arguments

Let me illustrate the first two problems with (a slight modification
of) the example on the page: http://www.scala-lang.org/node/138.

// Suppose we define a loop construct as follows:

object Loop {
 def loop(body: => Unit): LoopUnlessCond =
  new LoopUnlessCond(body)

 protected class LoopUnlessCond(body: => Unit) {
  def unless(cond: => Boolean) {
    body
    if (!cond) unless(cond)
  }
 }
}

// We can now use this as follows (use 1):

import Loop._

var i = 10
loop {
 println("i = " + i)
 i -= 1
} unless (i == 0)

// The above compiles and runs correctly. So far so good.

// Problem 1 : the eager semicolon.
// The following use (use 2) gives a compile time error:

i = 10
loop {
 println("i = " + i)
 i -= 1
}
unless (i == 0)

// This is because the unless method call is on a line for itself.
// Scala will at the '}' infer a semicolon too early. Hence the unless
// will no longer be a call of the method in class LoopUnlessCond.
// This is an example of Problem 1.

// Problem 2 : the satisfied semicolon.
// An example of Problem 2 is the following, which is missing the
// call of unless:

i = 10
loop {
 println("i = " + i)
 i -= 1
}

// this compiles correctly, but does not execute correctly. Nothing is printed.

// Problem 3 : the lazy semicolon.
// Suppose a constructs ends with a keyword, for example 'return' with
no arguments.
// Then one may want to write a class like:

class Return {
 def return() {...}
}

and have a construct like:

... return
somethingelse

The compiler will look for an argument to return and will find
’somethingelse’ and
will complain that return has too many arguments. So one has to insert
a semicolon to
make it work:

... return; // inserted semicolon here
somethingelse

// which is a pitty

Any opinions about these observations?

Regards,

Klaus

For example, when writing tens of thousands of lines with ActionScript I was bitten by the “optional semicolon” bug many times. There are myriad ways that you can have a statement span two lines which results in bugs (sometimes very hard-to-find bugs). Having to remember to format my lines so that the line terminator could be correctly inferred is, at best, irritating. I got bit enough times that I swore i would never use a language that doesn’t terminate its statements with a semicolon[1].

Sorry Scala, I like you and could probably learn to love you, except for the semicolon thing.

Justin

[1] I make an exception for Smalltalk. It uses periods to end statements. Besides, somehow ending lines with periods always seemed more natural to me than ending lines with semicolons, since that’s how I usually write English anyway.

a
-2

is this one statement ‘a-2′ or 2 statements where ‘-2′ is the return value? We can’t tell, not to mention the poor compiler. So, next time when you break a line, break it after an operator.

Overall, I’m a fan of semicolon inference. The blighters really are 99% redundant, and their absence contributes to Scala having some of the feel of a dynamic language like Python or Ruby. I agree that the “gotya” you outline is rather unpleasant, but I haven’t been bitten by anything like it yet in practice. Maybe I’ve just been fortunate!

I’m more ambivalent about Scala’s “equals-sign-vs-without” syntax for method declarations, which I’ve found rather unintuitive to learn. Still, the gotya you mention above is likely not a huge issue in practice, as I suspect the majority of the time accidentally omitting the equals will result in a compile-time type error at a call site. It’s also the sort of thing that could be readily flagged as a warning by the compiler or IDE.