Call to arms: lambda-case is stuck and needs your help

Jon Fairbairn jon.fairbairn at cl.cam.ac.uk
Fri Jul 13 10:51:47 CEST 2012


Mikhail Vorozhtsov <mikhail.vorozhtsov at gmail.com> writes:

> 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 at cl.cam.ac.uk




More information about the Glasgow-haskell-users mailing list