The problem is that this construct isn’t self-explanatory… even if one has learnt the basic feel of Scala. The more stuff like this a language has, the longer the learning curve is. That’s the issue. You’re asking someone new to find this web page for this cryptic construct, another page for another cryptic construct, etc., etc. Then, you have to find this page again when you forget how this non-intuitive thing works.

It’s a gradient scale but, eventually, newcomers will start to say, “There’s too much arcana here.” The more you put in, the worse it is.

I’m writing a natural language parser for my PhD project (I think Scala’s the best/most fun/most productive language). I want others to extend it eventually. So, I take the time to *type out* certain things in long form so that my intent is clear to another person trying to learn the language and my code *at the same time*, which is inevitable given Scala’s marginal status.

Scala is great but not perfect I wish everyone who likes it didn’t feel the need to defend every part of it, even when they don’t agree, e.g. “The reason I didn’t pick foldLeft is I didn’t want to have to explain how a method signature could have two sets of parentheses. Still seems pretty odd to me, but it’s actually valid syntax.”

>Another way of writing your reduction would be as follows:
>val mmax = numbers.reduceRight((a:Int, b:Int) => a.max(b))

Yet another way to phrase this is to use the original function more directly.
Assuming the original author’s function should have been called something
besides ‘max’ to avoid the name collision:

def mmax (a:Int, b:Int):Int = { if (a>=b) return a ; return b}

val nums = Array(1, 9, 3, -1, 11, 0)

then the reduceRight could also be applied as:

nums.reduceRight[Int](mmax(_,_))

val mmax = numbers.reduceRight((a:Int, b:Int) => a.max(b))

max(Int) is a method within class RichInt, to which any Int value can be implicitly coerced.

The type parameter for reduceRight is actually what allows us to use the underscores rather than properly typed values. The trick is that Scala cannot infer the types of the underscores without some sort of specified initial type. In this case, we’re giving Scala the return type explicitly, so it is able to infer the rest on its own. I considered using foldLeft instead of reduceLeft, but I thought that the added confusion of a curried function would obscure the point I was trying to make.

This is also a valid way of performing the reduce in the article:

numbers.foldLeft(0)(_+_)

I would expect:

bye.

b) (Not a question) Without operator-overloading or self defined operators, it wasn’t perfect clear to me, that I can use any self defined function instead of +, for example max:
scala> def max (a:Int, b:Int):Int = { if (a>=b) return a ; return b}
max: (Int,Int)Int

scala> val mmax = numbers.reduceRight[Int](_max_)
:5: error: not found: value _max_
val mmax = numbers.reduceRight[Int](_max_)
^
scala> val mmax = numbers.reduceRight[Int](_ max _)
mmax: Int = 5

Ah!

Perhaps you could add this to the scala wiki.

val sqlCols = columnNames.foldLeft(“”)(_ + “, ” + _)
assert sqlCols == “, name, id, value”

The leading comma won’t occur if reduce is used.

* if the iterable is of length 0, then it throws an exception
* if the iterable is of length 1, then it returns the single element
* if the iterable is of length 2+ then it stores the first element in a buffer, then repeatedly performs the binary operation on the buffer and an iterable element, storing the results in the buffer.

Okay, I guess only the FIRST element is being treated differently from the rest. Odd… but probably fairly useful. Handy, for instance, for cases like this:

val sqlCols = columnNames.reduceLeft[String](_ + “, ” + _)
val sqlQuery = “SELECT ” + sqlCols + ” FROM tableName WHERE ” + sqlWhere

– Michael Chermside