#4359: Implement lambda-case/lambda-if
---------------------------------+------------------------------------------
Reporter: batterseapower | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.4.1
Component: Compiler | Version: 7.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by claus):
Replying to [comment:33 simonmar]:
> I'm really surprised by both "complex language construct" and "limited
usage pattern" here, since those are both issues that I thought the
proposal addresses quite well.
"complex", as in made of many parts. Perhaps "monolithic" would be more to
the point. As for "limited usage pattern", I am not doubting the use case
for lambda-case (I'd use it myself). I am merely concerned that we have a
growing number of complex/monolithic language constructs, with partially
overlapping feature sets. Each of those language constructs covers one
(class of) use case(s), but we cannot keep adding language constructs for
each new use case.
If we could instead work out and expose the building blocks for these
language constructs, then a small set of building blocks could cover all
use cases. In other words, I'd like to see reuse not just by copy-and-
modify of "existing syntax and translations", but by having language
constructs that cover the shared features, with more complex language
constructs being defined in terms of those simpler constructs (defining
case-of in terms of case-as-a-function might be the most direct way to
achieve that, as far as this ticket is concerned, but case-of really wants
to be broken into smaller parts in the long run).
> > .. lambda-match (explicit match failure and fall-through)..
>
> Yes, I remember it, though I'd have to go and review the discussion to
fully understand the motivation. On the face of it the syntax looks a bit
strange (vertical bar is re-used).
Motivation in brief, in the context of this ticket: instead of turning
monolithic case into a function, turn each case alternative into a
function, and provide the means to recombine the alternatives.
It was really hard to find non-ambiguous syntax - the vertical bar was to
remind of algebraic datatype alternatives, but '''|pattern->body''' alone
had a corner case of ambiguity, so it became '''(|pattern->body)'''
instead. Adding guards back in ended up with '''(|pattern | guard ->
body)'''. That wasn't ideal, but read fairly well when using lambda-
matches as case alternatives.
I don't think it is necessary to go that way for this particular ticket,
but those who are showing interest in this ticket might find lambda-match
interesting as a next step.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4359#comment:34>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
