Comments on: You’d naturally write flatMap yourself if asked the question

By: Jedai

Jedai — Sat, 19 Jul 2008 21:31:10 +0000

That’s because just before this flatten was generalised to take a function of type A => List[B] instead, so in our case (x => x) is of type (List[X] => List[X]) where X is a single type, A is List[X] and B is X.
Then it all works out ! ^^

By: DavidLG

DavidLG — Fri, 27 Jun 2008 09:09:55 +0000

Hmm, I don’t quite understand. I think part of my confusion is that identity function. How does (foo:List[A]).flatten(x=>x) make sense if flatten takes an argument of type A=>List[A]? Unless I’m missing something basic, the types just don’t work.

By: Daniel Spiewak

Daniel Spiewak — Thu, 26 Jun 2008 13:59:05 +0000

Actually, Scala’s syntax for currying doesn’t let you drop the parentheses. In ML, you can do something like:

fun add a b = a + b

…and then invoke:

add 1 2

But unfortunately, Scala’s grammar does not allow this. The real advantage to currying is partially-applied functions. So you can define your add function as above, and then define a new function value which *specifically* adds a value to 10:

val addTen = add 10

Now you can invoke:

addTen 5

And the result is 15. This isn’t so useful in the trivial example, but once you start using it for larger things, you’ll never go back.

As mentioned above though, Scala allows partial application even for non-curried functions:

def add(a: Int, b: Int) = a + b

val addTen = add(10, _: Int)

Not really so clean as the curried alternative, but it still works. The curried form would be as follows:

def add(a: Int)(b: Int) = a + b

val addTen = add(10)

By: Jörn Zaefferer

Jörn Zaefferer — Thu, 26 Jun 2008 07:55:01 +0000

Thanks guys for the explanation. (A, A) => Boolean makes more sense to me, that was the missing link. I guess you prefer the curried signature because you can drop the parentheses.

By: Tony Morris

Tony Morris — Thu, 26 Jun 2008 00:47:04 +0000

Gah woops, that error in transcribing the type signature is potentially confusing, so I will repair it. The danger is of course, that this discussion now looks a little absurd.

Nevertheless, I think my mistake must be corrected in the main article.

Thanks for bringing it to my attention Daniel.

By: Daniel Spiewak

Daniel Spiewak — Wed, 25 Jun 2008 23:08:37 +0000

Oh, with regards to the API being broken: yeah, I’ll agree with that. It is a little absurd that with a type system as powerful as Scala’s, we’re still left working with super-defined methods of non-specific type. I wonder if flatMap actually casts the return result of the function value so that it can return the specific type of List[A]. Quite nasty.

By: Daniel Spiewak

Daniel Spiewak — Wed, 25 Jun 2008 23:04:27 +0000

To further elaborate on the A => A => Boolean issue, that’s not *actually* the signature of the function value. The given signature represents the curried form of (A, A) => Boolean, which is the type that the API actually accepts.

I do prefer the curried form in most languages, but Scala is forced to impose a bit more syntactic overhead on curried functions than pure-functional languages like ML or Haskell. I guess it depends on your needs, which is better in Scala. Neither is really more capable than the other since a) you can easily convert between the forms, and b) partially-applied functions are fairly easy in Scala even with uncurried methods.

By: Tony Morris

Tony Morris — Wed, 25 Jun 2008 19:49:21 +0000

Daniel, I agree. Change “completely” to “almost completely” or “mostly”. The fact that List[A].flatMap takes a forall B. (B => Iterable[B]) as an argument instead of a (A => List[B]) is completely absurd. Granted, it may have been written at a time when higher kinds did not exist in the language, but it is so fundamentally broken, it should be repaired. The fact that these methods are not final offers no resolve. To observe a correction, take a look at the Monad trait in Scalaz.

Jörn, sorry if that caused confusion. The method that takes that argument is called a Higher-Order Function (HOF) because that argument is itself, a function. It is a function takes two arguments of type A and returns a Boolean.

To represent similar in Java, you’d have to use an interface:

interface Whatever {
  &lt;A&gt; boolean whatever(A a1, A a2);
}

Then you would substitute A => A => Boolean with Whatever<A> in the method signature. It is simply the strategy for resolving the order of the element types of the List or specifically, whether the first argument is less than the second.

I hope this helps.

By: Jörn Zaefferer

Jörn Zaefferer — Wed, 25 Jun 2008 19:42:05 +0000

You lost me at “A => A => Boolean”, I don’t get what that means. Could you explain that, assuming a reader with no actual experience in functional programming?

By: Daniel Spiewak

Daniel Spiewak — Wed, 25 Jun 2008 16:27:29 +0000

I’m not sure I agree that Scala’s collections API is *completely* broken. Granted, methods like flatMap and similar are a little inefficient when applied to general Iterable containers, but the methods are not final. For example, List overrides map, fold*, flatMap, etc covariantly to return of type List. I haven’t looked at the actual implementation, but I assume that it’s a fairly efficient design.

To what specific breakage were you referring?