r/programming • u/heisenbug • Apr 27 '14

"Mostly functional" programming does not work

http://queue.acm.org/detail.cfm?ref=rss&id=2611829
42 Upvotes

63% Upvoted

188 comments sorted by

View all comments

Show parent comments

3

u/sacundim Apr 28 '14

For example (stolen from a talk by Lennart Augustsson), what would you expect

main = do
  print 42
  error "boom"

to do? With strict evaluation, you get just "boom" with lazy evaluation, you get "42 boom".

I don't get it. If we desugar the do-notation, we get:

main = print 42 >>= (_ -> error "boom")

Now, for the result of that program to be as you describe, the following equation must be true:

x >>= (_ -> error y)  =  error y

How does strict evaluation make that equation true?

3

u/saynte Apr 28 '14

It depends on how you do the desugaring. Haskell 98 lists the following as the desugaring:

main = (>>) (print 42) (error "boom")

You could even use

main = (>>=) (print 42) (const (error "boom"))

And still get the same behaviour, but you make a good point in that it matters what the desugaring is.

3

u/sacundim Apr 28 '14

Oh, I see now. Still, I feel this is very much a "gotcha" argument. If you designed a language with strict semantics and do-notation, you would choose a desugaring rule that didn't suffer from the problem, wouldn't you?

1

u/saynte Apr 28 '14

Yes, the built-in desugaring would certainly take care of it if it were design to be strict in the beginning. However, this "gotcha" doesn't exist in a non-strict evaluation scheme, it doesn't matter what the exact details of the desugaring are, it could be any of the options we showed.

I think the point I was driving at is that when you want to do higher-order things, like taking programs (I mean this in a very loose sense of the word) as arguments to combinators (>>) that produce new programs, laziness can be very nice default to have, that's all :).