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.