[Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Jon Fairbairn]

Ben Franksen  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.

As I was opposed to the suggestion for lambda case I didn’t
really follow the discussion of the syntax, but I’m puzzled by
the choice. To me it seems obvious that if we are going to do
this (as opposed to something more decomposable like
lambda-match), we should do it simply by making the “case exp”
part of a case expression optional. So the syntax for lambda-
case would be

   of {alts…}

and we would then describe

   case e of {…}

as syntactic sugar for

   (of {…}) (e)

Doing it this way doesn’t introduce any new syntactic elements
and has fewer tokens at the point of use.

I don’t see any need for a \ in the syntax: this is a functional
language we are talking about after all. Once we know that “of”
introduces a function, that should be enough.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Andreas Abel]

I had been missing a pattern matching lambda in Haskell for a long time 
(SML had "fn" since ages) and my typical use will be


  monadic_expr >>= \case
branches

I think "\case" is not the worst choice, certainly better than "of" ...

Thanks to the GHC 7.6 developers!

Cheers,
Andreas

On 29.11.12 12:49 PM, Jon Fairbairn wrote:

Ben Franksen  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.


As I was opposed to the suggestion for lambda case I didn’t
really follow the discussion of the syntax, but I’m puzzled by
the choice. To me it seems obvious that if we are going to do
this (as opposed to something more decomposable like
lambda-match), we should do it simply by making the “case exp”
part of a case expression optional. So the syntax for lambda-
case would be

of {alts…}

and we would then describe

case e of {…}

as syntactic sugar for

(of {…}) (e)

Doing it this way doesn’t introduce any new syntactic elements
and has fewer tokens at the point of use.

I don’t see any need for a \ in the syntax: this is a functional
language we are talking about after all. Once we know that “of”
introduces a function, that should be enough.



--
Andreas Abel  <><  Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Tom Ellis]

On Thu, Nov 29, 2012 at 05:49:53PM +, Jon Fairbairn wrote:
> Ben Franksen  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

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Petr P]

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 

> On Thu, Nov 29, 2012 at 05:49:53PM +, Jon Fairbairn wrote:
> > Ben Franksen  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

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[David Thomas]

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  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 
>
>> On Thu, Nov 29, 2012 at 05:49:53PM +, Jon Fairbairn wrote:
>> > Ben Franksen  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

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Chris Smith]

On Sun, Dec 30, 2012 at 8:51 AM, David Thomas wrote:

> Jon's suggestion sounds great.
>
> The bike shed should be green.
>

There were plenty of proposals that would work fine.  `case of` was great.
 `\ of` was great.  It's less obvious to me that stand-alone `of` is never
ambiguous... but if that's true, it's reasonable.  Sadly, the option that
was worse that doing nothing at all is what was implemented.

The "bikeshedding" nonsense is frustrating.  Bikeshedding is about wasting
time debating the minutia of a significant improvement, when everyone
agrees the improvement is a good idea.  Here, what happened was that
someone proposed a minor syntax tweak (from `\x -> case x of` to `case
of`), other reasonable minor syntax tweaks were proposed instead to
accomplish the same goal, and then in the end, out of the blue, it was
decided to turn `case` into a layout-inducing keyword (or even worse, only
sometimes but not always layout-inducing).

There is no bike shed here.  There are just colors (minor syntax tweaks).
 And I don't get the use of "bikeshedding" as basically just a rude comment
to be made at people who don't like the same syntax others do.

-- 
Chris
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Dan Burton]

My 2 cents on the issue:

We should have a better forms of meta-programming to solve this sort of
issue generally. With the power of first-class functions and laziness, we
can get away with a lot of things without meta-programming, but case
expression syntax is not first class, so cannot benefit from the
flexibility proffered to the rest of the language.

tl;dr give me easily extensible syntax, rather than having to run to GHC
devs every time I want a new or different flavor of sugar.

-- Dan Burton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[MigMit]

Syntax extensibility is usually too powerful, it surely would be abused 
extensively, which would make developer's life a nightmare, unless there is 
only one developer and whole development takes no more than a couple of months.

On Dec 31, 2012, at 1:09 AM, Dan Burton  wrote:

> My 2 cents on the issue:
> 
> We should have a better forms of meta-programming to solve this sort of issue 
> generally. With the power of first-class functions and laziness, we can get 
> away with a lot of things without meta-programming, but case expression 
> syntax is not first class, so cannot benefit from the flexibility proffered 
> to the rest of the language.
> 
> tl;dr give me easily extensible syntax, rather than having to run to GHC devs 
> every time I want a new or different flavor of sugar.
> 
> -- Dan Burton
> ___
> 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

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Dan Burton]

> [featureX] is usually too powerful, it surely would be abused extensively,
> which would make developer's life a nightmare, unless there is only one
> developer and whole development takes no more than a couple of months.


This doesn't say much about *why* syntax extension is too powerful, nor *how
*that would lead to extensive abuse. Well, "too powerful" or not,
meta-programming should be more easily available at least at *some *layer
of language development without having to resort to hacking the compiler.

-- Dan Burton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Brandon Allbery]

On Sun, Dec 30, 2012 at 8:42 PM, Dan Burton wrote:

> [featureX] is usually too powerful, it surely would be abused extensively,
>> which would make developer's life a nightmare, unless there is only one
>> developer and whole development takes no more than a couple of months.
>
>
> This doesn't say much about *why* syntax extension is too powerful, nor *how
> *that would lead to extensive abuse. Well, "too powerful" or not,
> meta-programming should be more easily available at least at *some *layer
> of language development without having to resort to hacking the compiler.
>

I think someone's already working on this (SugarHaskell?).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[adam vogt]

On Sun, Dec 30, 2012 at 10:00 PM, Brandon Allbery  wrote:
> On Sun, Dec 30, 2012 at 8:42 PM, Dan Burton 
> wrote:
>>>
>>> [featureX] is usually too powerful, it surely would be abused
>>> extensively, which would make developer's life a nightmare, unless there is
>>> only one developer and whole development takes no more than a couple of
>>> months.
>>
>>
>> This doesn't say much about why syntax extension is too powerful, nor how
>> that would lead to extensive abuse. Well, "too powerful" or not,
>> meta-programming should be more easily available at least at some layer of
>> language development without having to resort to hacking the compiler.
>
>
> I think someone's already working on this (SugarHaskell?).

Hi All,

Petr's suggestion has some similarities with this quasiquoter
,
at least as far as picking a different return type if some patterns
can fail. If new syntax implemented by a quasiquoter is really that
good, then these possible issues should be worth it:

- have to type [| |]
- haskell-src-exts parser called may not have the same extensions enabled as ghc
- when other new syntax is added, template haskell (and
haskell-src-meta) may not gain those features for a year or more

Regards,
Adam

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Tillmann Rendel]

Hi,

Brandon Allbery wrote:

[...] syntax extension [...]


I think someone's already working on this (SugarHaskell?).


Yes, we are working on it. See our paper [1] and Sebastian's talk [2] at 
the Haskell Symposium. Our current prototype can be installed as an 
Eclipse plugin [3] or as a command-line tool [4].


 [1] http://sugarj.org/sugarhaskell.pdf
 [2] http://www.youtube.com/watch?v=Kjm7bOLnuy0
 [3] http://update.sugarj.org/
 [4] http://hackage.haskell.org/package/sugarhaskell

One use case we have in mind for SugarHaskell is prototyping of language 
extensions like the one discussed in this thread.


  Tillmann

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe