Ben Franksen | 29 Nov 02:02 2012
Picon

A big hurray for lambda-case (and all the other good stuff)

Hi Everyone

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.

A big, huge thank you to the ghc developers. This has been sooooo long on my 
wish list.

Also much appreciated and long awaited: tuple sections (though I use them 
not quite as often).

Both should *definitely* go into Haskell'13.

Of course, thank you also for all the other beautiful stuff in ghc-7.6.1, 
especially PolyKinds, DataKinds etc.

GHC is just simply amazing. You guys RULE THE WORLD!

Cheers
--

-- 
Ben Franksen
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments
Jon Fairbairn | 29 Nov 18:49 2012
X-Face
Picon
Picon

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

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.

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.

(Continue reading)

Andreas Abel | 30 Nov 04:02 2012
Picon

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

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 <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.
>
> 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
(Continue reading)

Jon Fairbairn | 30 Nov 11:24 2012
X-Face
Picon
Picon

Re: lambda case

Andreas Abel <andreas.abel <at> ifi.lmu.de> writes:

> 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

We’ve been through that.  I want something similar, but would
have preferred something more algebraic.

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

What’s your argument? You’ll have to do better than blatant
assertion to convince me. Making “case exp” optional builds on
an existing expression syntax, giving an explicit meaning to a
part of it, so a reader only has to know that “of {alts}” is a
function and case does something specific with it. This “\case”
takes the keyword from that expression syntax and makes it a
special case of lambda, so a reader seeing a lambda now has to
check for a keyword instead of knowing straight off that the
next thing is going to be a variable.

Back when we originally designed Haskell there were lots of
things that people wanted to put in, and eventually we reached a
point where we said that we would only put something new in if
it allowed us to remove (or simplify) something else. “\case”
complicates lambda, using “of” simply breaks “case … of …” into
(Continue reading)

Herbert Valerio Riedel | 30 Nov 13:25 2012
Picon

Re: lambda case

Jon Fairbairn <jon.fairbairn <at> cl.cam.ac.uk> writes:

[...]

> “\case” complicates lambda, using “of” simply breaks “case … of …”
> into two easily understood parts.

Just some observation (I'm rather late to the lambda-case discussion, so
this might have been already pointed out previously):

if the reserved keyword 'of' was to take the place of '\case', shouldn't
then

  'case' exp

w/o the "'of' { alts }"-part become a separately valid expression (with
'case' essentially meaning 'flip ($)') to really break it up into two
independent parts? Then 'case exp of { alts }' wouldn't be a special
form anymore, but would just result from combining 'case' and 'of';

'case' wouldn't even need to be a reserved keyword (and thus the grammar
could be simplified), if it wasn't for the current grammar which
requires to isolate a \case-expression by using () or $, consider e.g.:

  {-# LANGUAGE LambdaCase #-}

  import System.Environment

  case' :: b -> (b -> c) -> c
  case' = flip ($)
(Continue reading)

Brent Yorgey | 30 Nov 15:52 2012

Re: lambda case

Oh, PLEASE people.  Let's not have another round of bikeshedding about
this AFTER the feature is already implemented!

-Brent

On Fri, Nov 30, 2012 at 01:25:27PM +0100, Herbert Valerio Riedel wrote:
> Jon Fairbairn <jon.fairbairn <at> cl.cam.ac.uk> writes:
> 
> [...]
> 
> > “\case” complicates lambda, using “of” simply breaks “case … of …”
> > into two easily understood parts.
> 
> Just some observation (I'm rather late to the lambda-case discussion, so
> this might have been already pointed out previously):
> 
> if the reserved keyword 'of' was to take the place of '\case', shouldn't
> then
> 
>   'case' exp
> 
> w/o the "'of' { alts }"-part become a separately valid expression (with
> 'case' essentially meaning 'flip ($)') to really break it up into two
> independent parts? Then 'case exp of { alts }' wouldn't be a special
> form anymore, but would just result from combining 'case' and 'of';
> 
> 'case' wouldn't even need to be a reserved keyword (and thus the grammar
> could be simplified), if it wasn't for the current grammar which
> requires to isolate a \case-expression by using () or $, consider e.g.:
> 
(Continue reading)

Roman Cheplyaka | 1 Dec 11:30 2012

Re: [Haskell-cafe] lambda case

It hasn't made it to the standard yet, though. If some experimental
feature is implemented in GHC, it doesn't mean it's set in stone.

I find this discussion useful — there are some interesting points
(splitting "case of" into two parts) that I don't remember reading in the
original thread (but maybe it's just me).

Roman

* Brent Yorgey <byorgey <at> seas.upenn.edu> [2012-11-30 09:52:53-0500]
> Oh, PLEASE people.  Let's not have another round of bikeshedding about
> this AFTER the feature is already implemented!
> 
> -Brent
> 
> On Fri, Nov 30, 2012 at 01:25:27PM +0100, Herbert Valerio Riedel wrote:
> > Jon Fairbairn <jon.fairbairn <at> cl.cam.ac.uk> writes:
> > 
> > [...]
> > 
> > > “\case” complicates lambda, using “of” simply breaks “case … of …”
> > > into two easily understood parts.
> > 
> > Just some observation (I'm rather late to the lambda-case discussion, so
> > this might have been already pointed out previously):
> > 
> > if the reserved keyword 'of' was to take the place of '\case', shouldn't
> > then
> > 
> >   'case' exp
(Continue reading)

Brandon Allbery | 1 Dec 14:43 2012
Picon

Re: [Haskell-cafe] lambda case

On Sat, Dec 1, 2012 at 5:30 AM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
I find this discussion useful — there are some interesting points
(splitting "case of" into two parts) that I don't remember reading in the
original thread (but maybe it's just me).

Mentioned twice that I recall, as treating 'of' as a lambda and as '\of'.  It got somewhat short shrift, likely because while it makes sense from an existing language syntax viewpoint, it makes little to none from a readability standpoint.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Jon Fairbairn | 3 Dec 16:17 2012
X-Face
Picon
Picon

Re: [Haskell-cafe] lambda case

Brandon Allbery <allbery.b <at> gmail.com> writes:

> On Sat, Dec 1, 2012 at 5:30 AM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
>
>> I find this discussion useful — there are some interesting points
>> (splitting "case of" into two parts) that I don't remember reading in the
>> original thread (but maybe it's just me).
>>
>
> Mentioned twice that I recall, as treating 'of' as a lambda and as '\of'.

I’m not quite sure what treating “of” as lambda means, and \of
raises the some of the same objections as \case.

Up until the introduction of “lambda-case”, \ was a clear
indication that what was coming next was a pattern that would
bind variables (except in degenerate cases, but anyone who
writes something like \Nothing -> e should be taken out and sho-
wn why it’s a bad idea).

>  It got somewhat short shrift, likely because while it makes sense from an
> existing language syntax viewpoint, it makes little to none from a
> readability standpoint.

Of the available alternatives, it makes the most linguistic
sense. If you can’t read the subtext for that sentence, try
again :-) In the design I was suggesting, “of” is in no sense a
lambda, it simply introduces a list of alternative patterns
exactly as it does in the original design of case … of {alts}.
Arguing about whether “of” is the right keyword here without
arguing that case… of… should have different keywords is
inconsistent, and arguing for a change of those keywords really
would be fussing about the colour of the bikeshed after it was
painted.

--

-- 
Jón Fairbairn                                 Jon.Fairbairn <at> cl.cam.ac.uk

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Jon Fairbairn | 3 Dec 16:03 2012
X-Face
Picon
Picon

Re: lambda case

Brent Yorgey <byorgey <at> seas.upenn.edu> writes:

> Oh, PLEASE people.  Let's not have another round of bikeshedding about
> this AFTER the feature is already implemented!

This is not an argument about the colour of the bikeshed. In
terms of that analogy, this has gone something like this:

Someone says the bikeshed doorknob is hard to turn and we should
have a handle. There’s some discussion, I say maybe, but lets
not do it unless we have a good design. Someone else comes up
with the beginnings of a good design for a handle, but there’s
no consensus about that and it all goes quiet. Some time later a
voice says that if nobody does anything it’ll get forgotten
(which is what I was hoping would happen). I repeat that it’s
better not to do it without a good design and nod off. When I
wake up, a handle has been installed by hot-melt glueing a bit
of rough sawn timber to the doorknob. I complain. Another voice
tells me to shut up, we’ve done it now.

  — Jón

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Andreas Abel | 30 Nov 15:55 2012
Picon

Re: lambda case

Right, case..of is superfluous,

   case e of
     branches

can now be written as

   e |> \case
     branches

with backwards application |> (or some prefer & --- sadly, the proposal 
to add backwards appliation to base did not make it to a consensus).

This is in accordance to the monadic

   me >>= \case
     branches

If there was an opportunity to make drastic language changes, case..of 
could be disposed of altogether.  \case could become 'cases' or 'match' 
or 'fun' (rather not 'of', for my taste).

The current compromise it not too bad, I think.

Unfortunately, I have to wait for 7.6 to become the standard before 
using \case in Agda source...

Cheers,
Andreas

On 30.11.12 7:25 AM, Herbert Valerio Riedel wrote:
> Jon Fairbairn <jon.fairbairn <at> cl.cam.ac.uk> writes:
>
> [...]
>
>> “\case” complicates lambda, using “of” simply breaks “case … of …”
>> into two easily understood parts.
>
> Just some observation (I'm rather late to the lambda-case discussion, so
> this might have been already pointed out previously):
>
> if the reserved keyword 'of' was to take the place of '\case', shouldn't
> then
>
>    'case' exp
>
> w/o the "'of' { alts }"-part become a separately valid expression (with
> 'case' essentially meaning 'flip ($)') to really break it up into two
> independent parts? Then 'case exp of { alts }' wouldn't be a special
> form anymore, but would just result from combining 'case' and 'of';
>
> 'case' wouldn't even need to be a reserved keyword (and thus the grammar
> could be simplified), if it wasn't for the current grammar which
> requires to isolate a \case-expression by using () or $, consider e.g.:
>
>    {-# LANGUAGE LambdaCase #-}
>
>    import System.Environment
>
>    case' :: b -> (b -> c) -> c
>    case' = flip ($)
>
>    main = do
>      s <- getArgs
>
>      case' s $ \case  -- image '\case' was actually '\of' or 'of'
>        [x] -> putStrLn ("Hello " ++ x)
>        _   -> putStrLn "wrong number of arguments given"
>
>
> just my 2¢
>
> cheers,
>    hvr
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

--

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

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

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Tom Ellis | 29 Dec 20:02 2012
Picon

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

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
Petr P | 30 Dec 16:44 2012
Picon

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

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:
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-2013 <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
David Thomas | 30 Dec 17:51 2012
Picon

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

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.mvd <at> 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:
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-2013 <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Chris Smith | 30 Dec 20:46 2012
Picon

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

On Sun, Dec 30, 2012 at 8:51 AM, David Thomas <davidleothomas <at> gmail.com> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Dan Burton | 30 Dec 22:09 2012
Picon

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

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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit | 30 Dec 22:27 2012
Picon

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

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 <danburton.email <at> gmail.com> 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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Dan Burton | 31 Dec 02:42 2012
Picon

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


[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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Brandon Allbery | 31 Dec 04:00 2012
Picon

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

On Sun, Dec 30, 2012 at 8:42 PM, Dan Burton <danburton.email <at> gmail.com> 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
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
adam vogt | 31 Dec 14:42 2012
Picon

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

On Sun, Dec 30, 2012 at 10:00 PM, Brandon Allbery <allbery.b <at> gmail.com> wrote:
> On Sun, Dec 30, 2012 at 8:42 PM, Dan Burton <danburton.email <at> gmail.com>
> 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
<http://hackage.haskell.org/packages/archive/applicative-quoters/0.1.0.8/doc/html/Control-Applicative-QQ-ADo.html>,
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
Tillmann Rendel | 1 Jan 20:36 2013
Picon

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

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

Gmane