another great comment!
You say “expectations for some reason go higher when it starts looking like a real programming language construct, which perhaps is unreasonable.”
You’re right, but I think also that if you give more power you need more safety too. Scala is like a Ferrari race car: as it can run so much, I expect it has good brakes too!!!


.unless |->Bool| {i == 0}


can occur on a line for itself. This is also the case in Scala if one uses the dot notation.

Below is the example in Scala with several uses, so one can see the different scenarios.

First the definition of the loop construct:

object Loop {
  def loop(stmt : => Unit) : Unless = {
    new Unless(stmt)
  }

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

import Loop._

Then the calls:

// call 1 (using mixfix notation - works):                                                                                        

var i : Int = 10;
loop {
  println(i)
  i = i - 1
} unless (i == 0)

// call 2 (also using mixfix notation, but with unless on a line for itself - gives a compile time error):                                                                           

i = 10;
loop {
  println(i)
  i = i - 1
}
unless (i == 0) // occurs on a line for itself - does not work

// Also, if this last line is left out, no error message is given.
// This is how other OO languages work. Not a problem as such in OO languages,
// but it does reduce the value of this mixfix notation for writing DSLs. It makes a DSL unsafe to use.

//  call 3 (using dot notation - works as expected):                                                                                          

i = 10;
loop {
  println(i)
  i = i - 1
}.unless(i == 0)

// call 4 (using dot notation, with unless on a line for itself - works):                                                                                           

i = 10;
loop {
  println(i)
  i = i - 1
}.
unless(i == 0) // occurs on a line for itself

Scala offers this mixfix notation for defining DSLs, and it looks very appealing. However, one can
provide only a partial instantiation of a DSL construct and the Scala compiler will be happy. We normally accept this in the case of dot-notation (that’s how it is in Java and Python) but our expectations for some reason go higher when it starts looking like a real programming language construct, which perhaps is unreasonable.
Something to think about. Could one think of imposing “static liveness” constraints? Like: ‘this intermediate object shouldnever be the result of a statement’.

Note that this problem can be avoided if instead we define the loop-unless construct as a curried function:

def loop_unless(stmt : => Unit)(cond : => Boolean) {
  stmt
  if(!cond)loop_unless(stmt)(cond)
}

Then one can write:

i = 20;
loop_unless {
  println(i)
  i = i - 1
} (i == 0)

However, if we write:

i = 20;
loop_unless {
  println(i)
  i = i - 1
}

leaving out the second parameter, the compiler will complain. This approach currently seems the safest way to
define DSLs in Scala.

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

Grazie ad Alberto per la segnalazione.

@Andrea. Sono contento che il post ti sia piacuto. Spero di incontrarti di persona a qualche meeting dell XPUG di Milano.

Poi ci sono le eccezioni che hanno una visione globale del mercato, ma sono le stesse eccezioni che in questo periodo stanno incrementando o almeno mantenendo, gli investimenti in R&D.

Come sempre, pare che la “ricerca e sviluppo” sia lasciata all’iniziativa del singolo :-/

Saluti
Pietro

Una ricerca su Google riporta brutte notizie: scheda madre bruciata. Vedi anche questo post, ed il citato manuale IBM.
In effetti anche da questo altro sito IBM si vede che i codici inizianti per B42 non sono di buon auspicio.

sono contento di esserle stato d’aiuto in qualche modo. Vorrebbe magare condividere la sua esperienza dandoci maggiori dettagli?

…cmq con un po’ di applicazione siamo riusciti a chiarire il corretto funzionamento della LAN Console; adesso possiamo averla su più PC, non contemporaneamente (ovviamente), e senza bisogno di smanettare forsennatamente sul pannellino ogni volta…. evviva il progresso!!!!

My doubt is about the manutenibility when you code from “JavaBean world” to “Fluent Interface world”

>DSL-like manner
It’s better

There is no problem, because I don’t use Struts
More seriously, obviously in this particular case, fluent interfaces (or functional setters as I love to call them ) are just setters that return the object itself, so I think they should work even with Struts.
Anyway, fluent interfaces are intended to develop in a DSL-like manner, not in the “old JavaBeans” standard.

Bye