Jon's suggestion sounds great.
The bike shed should be green.
That is all.
On Sun, Dec 30, 2012 at 4:44 PM, Petr P <petr....@gmail.com> wrote:
> Hi,
>
> I also support Jon's proposal for standalone of { ... }. Seems to me
> clearer and more useful than the special "\case" construct.
>
> I suppose 'of { ... }' could be generalized to multiple arguments, so that
> of (Just x) (Just y) -> x ++ y
> would create an anonymous function of type 'Maybe String -> Maybe String
> -> String'.
>
> Considering the recent thread about partial functions:
> http://www.haskell.org/pipermail/haskell-cafe/2012-December/105445.html
> 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:
> ofPart [x] [y] -> x ++ y
> 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. <
> http://www.scala-lang.org/api/current/scala/PartialFunction.html>
>
> [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.]
>
> We could even generalize 'ofPart' to work with any Alternative instance so
> that
> ofPart [x] [y] -> x ++ y
> 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
>
> fn = ofPart (Right 0) -> 1
> (Right x) -> x
>
> would produce (using today's syntax):
>
> fn :: (Alternative f) => Either Bool Int -> f Int
> fn x = case x of { Right 0 -> pure 1 ; _ -> empty; } <|>
> case x of { Right x -> pure x ; _ -> empty; } <|>
> empty
>
>
> Best regards,
> Petr
>
>
> 2012/12/29 Tom Ellis <tom-lists-haskell-cafe-2...@jaguarpaw.co.uk>
>
>> On Thu, Nov 29, 2012 at 05:49:53PM +0000, Jon Fairbairn wrote:
>> > Ben Franksen <ben.franksen at online.de> writes:
>> > > just wanted to drop by to say how much I like the new lambda case
>> extension.
>> > > I use it all the time and I just *love* how it relieves me from
>> conjuring up
>> > > dummy variables, which makes teh code not only esier to write but
>> also to
>> > > read.
>> >
>> > > [...] should *definitely* go into Haskell'13.
>> [...]
>> > To me it seems obvious that if we are going to do this [...] we should
>> do
>> > it simply by making the "case exp" part of a case expression optional.
>> >
>> > of {alts...}
>> >
>> > and we would then describe
>> >
>> > case e of {...}
>> >
>> > as syntactic sugar for
>> >
>> > (of {...}) (e)
>>
>> My very belated and unsolicited layman's reply is that I am a strong
>> supporter of Jon's position. His suggestion is parsimonious and natural.
>> Without wishing to start the discussion again, I disagree that it is
>> bikeshedding. One lesson I learned from Haskell is that syntax is much
>> more
>> important than I previously realised.
>>
>> Tom
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
