<div dir="ltr">Hi,<div><br></div><div>I also support Jon's proposal for standalone of { ... }. Seems to me clearer and more useful than the special "\case" construct.</div><div><br></div><div>I suppose 'of { ... }' could be generalized to multiple arguments, so that</div>
<div> of (Just x) (Just y) -> x ++ y</div><div>would create an anonymous function of type 'Maybe String -> Maybe String -> String'.</div><div><br></div><div>Considering the recent thread about partial functions:</div>
<div><a href="http://www.haskell.org/pipermail/haskell-cafe/2012-December/105445.html" target="_blank">http://www.haskell.org/pipermail/haskell-cafe/2012-December/105445.html</a><br></div><div>we could have variants of 'of' to distinguish partial functions. For example, we could have something like 'ofFull' that would require an exhaustive list of patterns, and something like 'ofPart' that would instead produce results of type 'Maybe something'. (Most likely we'd have to think of better names for them.) For example:</div>
<div> ofPart [x] [y] -> x ++ y</div><div>would be of type '[String] -> [String] -> Maybe String', returning `Nothing` if one of the input isn't a 1-element list - an approach similar to Scala's partial functions. <<a href="http://www.scala-lang.org/api/current/scala/PartialFunction.html">http://www.scala-lang.org/api/current/scala/PartialFunction.html</a>></div>
<div><br></div><div>[Perhaps we could have 'of' to work both ways - if the list of patterns would be exhaustive, the result would be pure. If it would be non-exhaustive, the result would be 'Maybe something'. Of course 'case x of ...' would still work as now, not caring about exhaustiveness. But I'm not sure if this wouldn't be too error prone.]</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>We could even generalize 'ofPart' to work with any Alternative instance so that</div><div> ofPart [x] [y] -> x ++ y</div>
<div>
would be of type '(Alternative f) => [String] -> [String] -> f String'. Matching patterns would return results using 'pure', non-matching 'empty', and they would be all combined combined using <|>. 'empty' would be returned if nothing matched. (Among other things, this could have some interesting consequences when overlapping patterns would be applied to 'Alternative []'.) For example</div>
<div><br></div><div><font class="Apple-style-span" face="'courier new', monospace">fn = ofPart (Right 0) -> 1</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> (Right x) -> x</font></div>
<div><br></div><div>would produce (using today's syntax):</div><div><br></div><div><div><font class="Apple-style-span" face="'courier new', monospace">fn :: (Alternative f) => Either Bool Int -> f Int</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">fn x = case x of { Right 0 -> pure 1 ; _ -> empty; } <|></font></div><div><font class="Apple-style-span" face="'courier new', monospace"> case x of { Right x -> pure x ; _ -> empty; } <|></font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> empty</font></div></div><div><br></div><div><br></div><div>Best regards,</div><div>Petr</div><meta http-equiv="content-type" content="text/html; charset=utf-8">
<div class="gmail_extra"><br><br><div class="gmail_quote">2012/12/29 Tom Ellis <span dir="ltr"><<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>></span><br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Thu, Nov 29, 2012 at 05:49:53PM +0000, Jon Fairbairn wrote:<br>
> Ben Franksen <ben.franksen at <a href="http://online.de" target="_blank">online.de</a>> writes:<br>
> > just wanted to drop by to say how much I like the new lambda case extension.<br>
> > I use it all the time and I just *love* how it relieves me from conjuring up<br>
> > dummy variables, which makes teh code not only esier to write but also to<br>
> > read.<br>
><br>
</div>> > [...] should *definitely* go into Haskell'13.<br>
[...]<br>
> To me it seems obvious that if we are going to do this [...] we should do<br>
<div>> it simply by making the "case exp" part of a case expression optional.<br>
><br>
</div>> of {alts...}<br>
<div>><br>
> and we would then describe<br>
><br>
</div>> case e of {...}<br>
><br>
> as syntactic sugar for<br>
><br>
> (of {...}) (e)<br>
<br>
My very belated and unsolicited layman's reply is that I am a strong<br>
supporter of Jon's position. His suggestion is parsimonious and natural.<br>
Without wishing to start the discussion again, I disagree that it is<br>
bikeshedding. One lesson I learned from Haskell is that syntax is much more<br>
important than I previously realised.<br>
<span><font color="#888888"><br>
Tom<br>
</font></span><div><div><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div></div>