The comparison goes like this: you have the same program (OO Hello World) implemented in 19 languages using exactly the same features and rules) and then compare them based on some metrics. The comparisons so far are between Keywords and Lines of code

Fantom:
http://carlosqt.blogspot.com/2010/07/oo-hello-world-fantom.html
Scala:
http://carlosqt.blogspot.com/2010/07/oo-hello-world-scala.html

Then you have:
http://carlosqt.blogspot.com/2010/07/how-many-keywords-do-you-type-in-your.html
and
http://carlosqt.blogspot.com/2010/07/how-many-lines-to-code-same.html

Hi Franco! Two things:

- a tail-recursive solution is just like a while loop in a different syntax

- you can gain a lot of readability in functional languages if you think of composing functions like building blocks.

Have fun!

Matteo,

I forgot to mention that I chose not to use a tail-recursive solution in order to improve readability, since the problem involves a small amounts of recursive calls.

I’ll try to improve my functional programming skills using your advice: thanks!

Claudio

package net.fl.clojure

object ClojureDemoGeneric {
  case class RichList[A] (list : List[A]) {
    def isOrderedBy(f: (A, A) => Boolean) : Boolean = list match {
      case Nil => true
      case x :: Nil => true
      case x :: y :: xs => f(x, y) && new RichList[A](y :: xs).isOrderedBy(f)
    }
  }

  implicit def listConverter[A] (list: List[A]) = new RichList[A](list)  

  def main(args : Array[String]) : Unit = {
    //lexicographic ordering: prints true
    println(List("a", "c", "z").isOrderedBy(_ < _))

    //natural nubers ordering: prints false
    println(List(1, 20, 4) isOrderedBy (_ < _))

    //floating point ordering: prints true
    println((1.0 :: 2.5 :: 3.9 :: Nil).isOrderedBy(_ < _))

    //custom ordering: prints false
    println(List("one", 2, 3.0) isOrderedBy ((x, y) => x.toString() < y .toString()))
  }
}

regards
nibble

My point is that, with a flexible language like Scala, you can have many solutions: you can use the prefix notation, or the infix one if you feel it better. In other languages you have only one choice, which, I think, most of the times is far less readable.

The original premise was built on finding the monotonically increasing order of a number of arguments, which in Scala could be written as a function isminc:

def isminc(a:Int, b:Int, c:Int, d:Int, e:Int):Boolean = a < b && b < c && c < d && d < e
isminc(1,2,3,4,5)
res6: Boolean = true

That’s Scala, not C. You know the Clojure solution, so there is no need to cover that ground, but let’s put it into a function:

(defn minc? [a b c d e] (< a b c d e))
(minc? 1 2 3 4 5)
true

This is the original premise, and I would contest that the Clojure example is far more readable. However, by changing the problem in the way you did, you’ve actually helped to prove my original point. That is, you’ve taken a problem solved by a somewhat verbose infix solution, put it into a list and made it into a more flexible method call *prefix* solution. Your way (or some variant thereof… I would have probably used a Trait instead, but I realize that you want to keep things as compact as possible) was probably the correct way to solve this particular problem. But what happens if you need to compare more than just Ints? What if you need to mix them? BTW: I like Scala and I use it every day, so don’t take this as a slam against it. Instead, people like to pick and choose straw-man arguments against prefix notation without thinking through the vast number of cases where it makes sense. Even if your code was littered with a vast number of 1 + 2 then it’s debatable that using (+ 1 2) instead makes things harder to read.

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.