Mikhail Vorozhtsov
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals!
P.S. I'm CC-ing Cafe to attract more people, but please keep the discussion to the GHC Users list.
[1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching [2] http://hackage.haskell.org/trac/ghc/ticket/4359
Apart from lambda match, the suggestions seem to me to be poor solutions to an old piece of bad design and they don’t fit very well with the look of haskell. Way back at the beginning of time, I was against pattern matching altogether as it seemed like a seductive feature that wouldn’t generalise very well. I wanted algebraic combinations of some form of guarded expressions. But the rest of the committee wanted pattern matching (I think they were right — the seductive aspect is important and if I had had my way Haskell would not have been as popular as it is now) and it seemed logical to have pattern matching in lambdas too. But that led to lambdas that can fail, which I think was a bad decision. What I would rather have happen now is that we introduce a distinction between pure destructor patterns (where a type is not a sum) and patterns that can fail. Then mandate that at some future date \pattern1 -> expression will be invalid unless pattern1 is a pure destructor, (but to begin with the compiler would just issue a warning). Now \pattern1 -> expression has type a -> b without a hidden exception. Then add another lambda for patterns that can fail, eg \? pattern -> expression, which has a type reflecting the fact that the match can fail, eg a -> Maybe b. Add operators to combine such lambda expressions (eg a symbol — on the lines of || — for liftA2 mplus) and a means of getting the answer out when all the bases are covered (something a bit handier than just having an operator for liftA2 fromMaybe, though that would cover all the use cases that end with \? _ -> e). lambda match is very close to that and worked out in more detail. So I’m against the other proposals. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk