Call to arms: lambda-case is stuck and needs your help

[Mikhail Vorozhtsov]

Hi.

After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the ticket[2], vote and comment on the proposals!

P.S. I'm CC-ing Cafe to attract more people, but please keep the
discussion to the GHC Users list.

[1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching
[2] http://hackage.haskell.org/trac/ghc/ticket/4359

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Christopher Done-2]

I like \case as is proposed. It seems the least controversial one and
there's curry (\case ) for two-args, but even that seems a rare case.

For what it's worth, I like the idea of omission being partiality, as
in case of and if then. It seems perfectly natural to me, I don't need
a \ to tell me that an expression will result in a function. But some
do. So I'll go along with and vote for \case. The lack of a lambda
case is one of the few "legitimate" complaints I have about Haskell's
syntax so it would be marvey to see it in GHC.

P.S. \if then … else …?

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Daniel Wagner]

Quoting Mikhail Vorozhtsov <[hidden email]>:

> After 21 months of occasional arguing the lambda-case proposal(s) is  
> in danger of being buried under its own trac ticket comments. We  
> need fresh blood to finally reach an agreement on the syntax. Read  
> the wiki page[1], take a look at the ticket[2], vote and comment on  
> the proposals!
>
> P.S. I'm CC-ing Cafe to attract more people, but please keep the  
> discussion to the GHC Users list.
>
> [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching
> [2] http://hackage.haskell.org/trac/ghc/ticket/4359

Well, for what it's worth, my vote goes for a multi-argument \case. I  
find the comment on the wiki page about mistyping "\case Just x"  
instead of "\case (Just x)" a lot a bit disingenuous, since you  
already need these parens with today's lambda. The complaint that  
multi-argument cases are unorthodox doesn't really hold a lot of  
weight with me -- much more serious things than syntax have changed in  
GHC compared to the Report!

Is there a more formal way to cast votes...?
~d

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Felipe Almeida Lessa]

On Thu, Jul 5, 2012 at 12:21 PM, Christopher Done <[hidden email]> wrote:
> I like \case as is proposed. It seems the least controversial one and
> there's curry (\case ) for two-args, but even that seems a rare case.
>
> For what it's worth, I like the idea of omission being partiality, as
> in case of and if then. It seems perfectly natural to me, I don't need
> a \ to tell me that an expression will result in a function. But some
> do. So I'll go along with and vote for \case. The lack of a lambda
> case is one of the few "legitimate" complaints I have about Haskell's
> syntax so it would be marvey to see it in GHC.

+1 for \case, I completely agree with Christopher Done.

Cheers,

--
Felipe.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Twan van Laarhoven]

On 05/07/12 17:22, [hidden email] wrote:
> Well, for what it's worth, my vote goes for a multi-argument \case. I find the
> comment on the wiki page about mistyping "\case Just x" instead of "\case (Just
> x)" a lot a bit disingenuous, since you already need these parens with today's
> lambda.

But you don't need parentheses with today's case. I.e. you write

     \x -> case v of
             Just x -> y
             Nothing -> z

then you would also expect to be able to write

     \case
             Just x -> y
             Nothing -> z

And \case looks more like case than like lambda, particularly because it uses
layout.



As for single argument \case, I don't really see the need for it, but I am not
against. So I'll abstain from voting.



Twan

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Gábor Lehel]

On Thu, Jul 5, 2012 at 5:21 PM, Christopher Done <[hidden email]> wrote:
> I like \case as is proposed. It seems the least controversial one and
> there's curry (\case ) for two-args, but even that seems a rare case.
>
> For what it's worth, I like the idea of omission being partiality, as
> in case of and if then. It seems perfectly natural to me, I don't need
> a \ to tell me that an expression will result in a function. But some
> do. So I'll go along with and vote for \case. The lack of a lambda
> case is one of the few "legitimate" complaints I have about Haskell's
> syntax so it would be marvey to see it in GHC.

I agree. I think the partial application metaphor in "case of" is very
nice, but \case is okay enough, so I'm voting for whatever is most
popular as long as it does the job and doesn't break compatibility.

>
> P.S. \if then … else …?
>

I'd prefer just getting a function of type a -> a -> Bool -> a and
partially applying it. We need a language level solution for case
because case of is fundamental and you can't do that. But if then else
is just sugar.
(That being said one of my principles is to trust people not to make
their own code ugly on purpose, so if people really want partially
applied if then else then I guess let them have it else who cares. But
I don't really see the case for it.)


--
Your ship was caught in a monadic eruption.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Daniel Wagner]

Quoting [hidden email]:

> Well, for what it's worth, my vote goes for a multi-argument \case. I

Just saw a proposal for \of on the reddit post about this. That's even  
better, since:

1. it doesn't change the list of block heralds
2. it doesn't mention case, and therefore multi-arg \of is perhaps a  
bit less objectionable to those who expect "case" to be single-argument
3. 40% less typing!

Can I change my vote? =)
~d

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Tyson Whitehead]

On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
> After 21 months of occasional arguing the lambda-case proposal(s) is in
> danger of being buried under its own trac ticket comments. We need fresh
> blood to finally reach an agreement on the syntax. Read the wiki
> page[1], take a look at the ticket[2], vote and comment on the proposals!

If I understand correctly, we currently we have

  \ apat1 ... apatn -> exp

The possibility using '\' as a layout herald (like let, do, etc.)

  \ { apat1 ... apatn -> exp; ... }

is suggested on the wiki, but rejected because code like so

  mask $ \restore -> do
    stmt1
    ...

by translating it into (Section 9.3 of the 98 Report)

  mask $ \ { restore -> do { }
    } stmt1

  http://www.haskell.org/onlinereport/syntax-iso.html

The reason for this is

1 - the layout level for '\' is the column of the 'restore' token

2 - the layout level for 'do' would be the column of the first token of 'stmt1'

3 - the '\' level is greater than the potential 'do' level so the fall through
'{}' insertion rule fires instead of the desired '{' insertion rule

4 - the '\' level is greater than the identation level for the first token of
'stms1' (now established to not be part of the 'do') so the '}' rule fires

Why not just let enclosed scopes be less indented than their outer ones?

It would then correctly translate the above.  This of course implies that any
code that requires the original translation (i.e., where the last of multiple
enclosing blocks should be an empty block) would no longer work.

Is any code actually relying on this though?  It seems like a pretty esoteric
corner case.  If not, my vote would be to relax this rule and go with '\'
being a layout hearld with full case style matching (i.e., guards too).

Cheers!  -Tyson

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Edward Kmett]

I really like the \of proposal!

It is a clean elision with \x -> case x of becoming \of

I still don't like it directly for multiple arguments.

One possible approach to multiple arguments is what we use for multi-argument case/alt here in our little haskell-like language, Ermine, here at S&P CapitalIQ, we allow for ',' separated patterns, but without surrounding parens to be treated as a multi argument case and alt pair. Internally we desugar our usual top level bindings directly to this representation. When mixed with the \of extension, this would give you:

foo :: Num a => Maybe a -> Maybe a -> Maybe a
foo = \of
  Just x, Just y -> Just (x*y)
  _, _ -> Nothing

but it wouldn't incur parens for the usual constructor pattern matches and it sits cleanly in another syntactic hole.

A similar generalization can be applied to the expression between case and of to permit a , separated list of expressions so this becomes applicable to the usual case construct. A naked unparenthesized , is illegal there currently as well. That would effectively be constructing then matching on an unboxed tuple without the (#, #) noise, but that can be viewed as a separate proposal' then the above is just the elision of the case component of:

foo mx my = case mx, my of
  Just x, Just y -> Just (x*y)
  _, _ -> Nothing

On Jul 5, 2012, at 2:49 PM, [hidden email] wrote:

> Quoting [hidden email]:
>
>> Well, for what it's worth, my vote goes for a multi-argument \case. I
>
> Just saw a proposal for \of on the reddit post about this. That's even better, since:
>
> 1. it doesn't change the list of block heralds
> 2. it doesn't mention case, and therefore multi-arg \of is perhaps a bit less objectionable to those who expect "case" to be single-argument
> 3. 40% less typing!
>
> Can I change my vote? =)
> ~d
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Twan van Laarhoven]

On 2012-07-05 23:04, Edward Kmett wrote:
> A similar generalization can be applied to the expression between case and of
> to permit a , separated list of expressions so this becomes applicable to the
> usual case construct. A naked unparenthesized , is illegal there currently as
> well. That would effectively be constructing then matching on an unboxed
> tuple without the (#, #) noise, but that can be viewed as a separate
> proposal' then the above is just the elision of the case component of:

Should that also generalize to nullarry 'case of'? As in

     foo = case of
            | guard1 -> bar
            | guard2 -> baz

instead of

     foo = case () of
         () | guard1 -> bar
            | guard2 -> baz



I realize this is getting off-topic, and has become orthogonal to the single
argument λcase proposal.


Twan

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Donn Cave-4]

The `multi-clause lambda' seems more elegant, if the syntactical
problems could be worked out.  I mean, unnamed functions are thus
just like named functions, something that you'd probably think to
try just as soon as you needed the feature.

I don't understand the issues well enough with the layout rules to
comment on Tyson Whitehead's ideas about that, and for the same
reason this may be a useless idea, but what if each clause were
introduced by \, would that clarify the column structure, or does
indented block structure require a less-indented `layout herald'?

  f = \ (Just a) (Just b) | a < 0 || b < 0 -> Nothing
      \ (Just a) (Just b) -> Just (a * b)
      \ _ _ -> Nothing

        Donn

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Mikhail Vorozhtsov]

On 07/06/2012 04:33 AM, Twan van Laarhoven wrote:

> On 2012-07-05 23:04, Edward Kmett wrote:
>> A similar generalization can be applied to the expression between case
>> and of
>> to permit a , separated list of expressions so this becomes applicable
>> to the
>> usual case construct. A naked unparenthesized , is illegal there
>> currently as
>> well. That would effectively be constructing then matching on an unboxed
>> tuple without the (#, #) noise, but that can be viewed as a separate
>> proposal' then the above is just the elision of the case component of:
>
> Should that also generalize to nullarry 'case of'? As in
>
>      foo = case of
>             | guard1 -> bar
>             | guard2 -> baz
>
> instead of
>
>      foo = case () of
>          () | guard1 -> bar
>             | guard2 -> baz
>
>
>
> I realize this is getting off-topic, and has become orthogonal to the
> single argument λcase proposal.

Yes, there is a separate proposal for that:
http://hackage.haskell.org/trac/haskell-prime/wiki/MultiWayIf

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Mikhail Vorozhtsov]

On 07/06/2012 05:47 AM, Donn Cave wrote:

> The `multi-clause lambda' seems more elegant, if the syntactical
> problems could be worked out.  I mean, unnamed functions are thus
> just like named functions, something that you'd probably think to
> try just as soon as you needed the feature.
>
> I don't understand the issues well enough with the layout rules to
> comment on Tyson Whitehead's ideas about that, and for the same
> reason this may be a useless idea, but what if each clause were
> introduced by \, would that clarify the column structure, or does
> indented block structure require a less-indented `layout herald'?
>
>    f = \ (Just a) (Just b) | a < 0 || b < 0 -> Nothing
>        \ (Just a) (Just b) -> Just (a * b)
>        \ _ _ -> Nothing
>
> Donn

This was suggested in the ticket comments, see
http://hackage.haskell.org/trac/ghc/ticket/4359#comment:29
I'll add it to the list.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Mikhail Vorozhtsov]

On 07/05/2012 10:22 PM, [hidden email] wrote:

> Quoting Mikhail Vorozhtsov <[hidden email]>:
>
>> After 21 months of occasional arguing the lambda-case proposal(s) is
>> in danger of being buried under its own trac ticket comments. We need
>> fresh blood to finally reach an agreement on the syntax. Read the wiki
>> page[1], take a look at the ticket[2], vote and comment on the proposals!
>>
>> P.S. I'm CC-ing Cafe to attract more people, but please keep the
>> discussion to the GHC Users list.
>>
>> [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching
>> [2] http://hackage.haskell.org/trac/ghc/ticket/4359
>
> Well, for what it's worth, my vote goes for a multi-argument \case. I
> find the comment on the wiki page about mistyping "\case Just x" instead
> of "\case (Just x)" a lot a bit disingenuous, since you already need
> these parens with today's lambda. The complaint that multi-argument
> cases are unorthodox doesn't really hold a lot of weight with me -- much
> more serious things than syntax have changed in GHC compared to the Report!

\case does /not/ require parentheses. I wrote about forgetting them when
using MultiClauseLambdas, e.g.

\(A b) -> ... -- \ here reminds me to use ()
  (C d) -> ...
  ...
  Y z -> ... -- After a while I forget about them because all I see is
             -- Pat -> Expr, and that's instantly a case-expression
             -- alternative clause for me.

This might as well be just my personal thing.

> Is there a more formal way to cast votes...?
People are still coming up with new tweaks. I'll write a summary email
with the voted (so far) proposals list, maybe it will be easier to go on
from there.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Edward Kmett]

Oh, neat. I guess it does. :) I'll hack that into my grammar when I get into work tomorrow.

My main point with that observation is it cleanly allows for multiple argument \of without breaking the intuition you get from how of already works/looks or requiring you to refactor subsequent lines, to cram parens or other odd bits of syntax in, but still lets the multi-argument crowd have a way to make multi-argument lambdas with all of the expected appropriate backtracking, if they want them. I definitely prefer \of to \case given its almost shocking brevity and the fact that the fact that it introduces a layout rule doesn't change any of the rules for when layout is introduced.

On Jul 5, 2012, at 5:33 PM, Twan van Laarhoven <[hidden email]> wrote:

> On 2012-07-05 23:04, Edward Kmett wrote:
>> A similar generalization can be applied to the expression between case and of
>> to permit a , separated list of expressions so this becomes applicable to the
>> usual case construct. A naked unparenthesized , is illegal there currently as
>> well. That would effectively be constructing then matching on an unboxed
>> tuple without the (#, #) noise, but that can be viewed as a separate
>> proposal' then the above is just the elision of the case component of:
>
> Should that also generalize to nullarry 'case of'? As in
>
>    foo = case of
>           | guard1 -> bar
>           | guard2 -> baz
>
> instead of
>
>    foo = case () of
>        () | guard1 -> bar
>           | guard2 -> baz
>
>
>
> I realize this is getting off-topic, and has become orthogonal to the single argument λcase proposal.
>
>
> Twan
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Mikhail Vorozhtsov]

On 07/06/2012 02:31 AM, Tyson Whitehead wrote:

> On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
>> After 21 months of occasional arguing the lambda-case proposal(s) is in
>> danger of being buried under its own trac ticket comments. We need fresh
>> blood to finally reach an agreement on the syntax. Read the wiki
>> page[1], take a look at the ticket[2], vote and comment on the proposals!
>
> If I understand correctly, we currently we have
>
>    \ apat1 ... apatn -> exp
>
> The possibility using '\' as a layout herald (like let, do, etc.)
>
>    \ { apat1 ... apatn -> exp; ... }
>
> is suggested on the wiki, but rejected because code like so
>
>    mask $ \restore -> do
>      stmt1
>      ...
>
> by translating it into (Section 9.3 of the 98 Report)
>
>    mask $ \ { restore -> do { }
>      } stmt1
>
>    http://www.haskell.org/onlinereport/syntax-iso.html
>
> The reason for this is
>
> 1 - the layout level for '\' is the column of the 'restore' token
>
> 2 - the layout level for 'do' would be the column of the first token of 'stmt1'
>
> 3 - the '\' level is greater than the potential 'do' level so the fall through
> '{}' insertion rule fires instead of the desired '{' insertion rule
>
> 4 - the '\' level is greater than the identation level for the first token of
> 'stms1' (now established to not be part of the 'do') so the '}' rule fires
>
> Why not just let enclosed scopes be less indented than their outer ones?
>
> It would then correctly translate the above.  This of course implies that any
> code that requires the original translation (i.e., where the last of multiple
> enclosing blocks should be an empty block) would no longer work.
>
> Is any code actually relying on this though?  It seems like a pretty esoteric
> corner case.  If not, my vote would be to relax this rule and go with '\'
> being a layout hearld with full case style matching (i.e., guards too).

Hm, would it work for

getArgs >>= \args ->
   forM_ args putStrLn

?

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Mikhail Vorozhtsov]

On 07/05/2012 09:42 PM, Mikhail Vorozhtsov wrote:

> Hi.
>
> After 21 months of occasional arguing the lambda-case proposal(s) is in
> danger of being buried under its own trac ticket comments. We need fresh
> blood to finally reach an agreement on the syntax. Read the wiki
> page[1], take a look at the ticket[2], vote and comment on the proposals!
>
> P.S. I'm CC-ing Cafe to attract more people, but please keep the
> discussion to the GHC Users list.
>
> [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching
> [2] http://hackage.haskell.org/trac/ghc/ticket/4359

Preliminary votes:
* LambdaCase \case: 3 (Christopher, Felipe, Gábor)
* LambdaCase \of: 1 (Edward)
* MultiClauseLambdas \of: 1 (Daniel)
* MultiClauseLambdas with \ in each clause: 1 (Donn)
* MultiClauseLambdas with layout rules tweaking: 1 (Tyson)

Note that LambdaCase variants do /not/ require parentheses around
patterns while MultiClauseLambdas variants do.

Did I forget/misunderstand someone?

It would be great to have GHC HQ input on the new proposals (layout
rules tweaking (Tyson) and case comma sugar (Edward)).

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Edward Kmett]

Twan, 

The 0-ary version you proposed actually works even nicer with \of.

foo'' = case () of

  () | quux -> ...

     | quaffle -> ...

     | otherwise -> ...

Starting from the above legal haskell multi-way if, we can, switch to 

foo' = case of

  | quux -> ...

  | quaffle -> ...

  | otherwise -> ...

using the 0-ary form of case as a multi-way if, but since the motivation was to allow the min \of, we get the very terse 

foo = \of | quux -> ...

          | quaffle -> ...

          | otherwise -> ...

and you get wind up with layout starting on the |'s so they line up per-force.

baz = \of 

  Just x  -> Just (x + 1)

  Nothing -> Nothing

avoids an ugly temporary for 

baz' mx = case mx of

  Just x -> Just (x + 1)

  Nothing -> Nothing

and in the multi-argument case, the resulting syntax is actually comparably noisy to the direct declaration syntax. One , as opposed to two pairs of parentheses in bar''' below.

bar = \of Just x, Just y -> Just (x + y)

          _     , _      -> Nothing

bar' mx my = case mx, my of

  Just x, Just y -> Just (x + y)

  _     , _      -> Nothing

 

bar'' mx my = case (# mx, my #) of

  (# Just x, Just y #) -> Just (x + y)

  (# _     , _      #) -> Nothing

bar''' (Just x) (Just y) = Just (x + y)

bar''' _ _ = Nothing

-Edward

On Fri, Jul 6, 2012 at 3:12 AM, Edward Kmett <[hidden email]> wrote:

Oh, neat. I guess it does. :) I'll hack that into my grammar when I get into work tomorrow.

My main point with that observation is it cleanly allows for multiple argument \of without breaking the intuition you get from how of already works/looks or requiring you to refactor subsequent lines, to cram parens or other odd bits of syntax in, but still lets the multi-argument crowd have a way to make multi-argument lambdas with all of the expected appropriate backtracking, if they want them. I definitely prefer \of to \case given its almost shocking brevity and the fact that the fact that it introduces a layout rule doesn't change any of the rules for when layout is introduced.

On Jul 5, 2012, at 5:33 PM, Twan van Laarhoven <[hidden email]> wrote:

> On 2012-07-05 23:04, Edward Kmett wrote:
>> A similar generalization can be applied to the expression between case and of
>> to permit a , separated list of expressions so this becomes applicable to the
>> usual case construct. A naked unparenthesized , is illegal there currently as
>> well. That would effectively be constructing then matching on an unboxed
>> tuple without the (#, #) noise, but that can be viewed as a separate
>> proposal' then the above is just the elision of the case component of:
>
> Should that also generalize to nullarry 'case of'? As in
>
>    foo = case of
>           | guard1 -> bar
>           | guard2 -> baz
>
> instead of
>
>    foo = case () of
>        () | guard1 -> bar
>           | guard2 -> baz
>
>
>
> I realize this is getting off-topic, and has become orthogonal to the single argument λcase proposal.
>
>
> Twan
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Herbert Valerio Riedel]

Christopher Done <[hidden email]> writes:

> P.S. \if then … else …?

btw, http://www.haskell.org/haskellwiki/If-then-else

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Simon Marlow-7]

On 05/07/2012 20:31, Tyson Whitehead wrote:

> On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
>> After 21 months of occasional arguing the lambda-case proposal(s) is in
>> danger of being buried under its own trac ticket comments. We need fresh
>> blood to finally reach an agreement on the syntax. Read the wiki
>> page[1], take a look at the ticket[2], vote and comment on the proposals!
>
> If I understand correctly, we currently we have
>
>    \ apat1 ... apatn -> exp
>
> The possibility using '\' as a layout herald (like let, do, etc.)
>
>    \ { apat1 ... apatn -> exp; ... }
>
> is suggested on the wiki, but rejected because code like so
>
>    mask $ \restore -> do
>      stmt1
>      ...
>
> by translating it into (Section 9.3 of the 98 Report)
>
>    mask $ \ { restore -> do { }
>      } stmt1
>
>    http://www.haskell.org/onlinereport/syntax-iso.html
>
> The reason for this is
>
> 1 - the layout level for '\' is the column of the 'restore' token
>
> 2 - the layout level for 'do' would be the column of the first token of 'stmt1'
>
> 3 - the '\' level is greater than the potential 'do' level so the fall through
> '{}' insertion rule fires instead of the desired '{' insertion rule
>
> 4 - the '\' level is greater than the identation level for the first token of
> 'stms1' (now established to not be part of the 'do') so the '}' rule fires
>
> Why not just let enclosed scopes be less indented than their outer ones?

I think this is undesirable.  You get strange effects like

   f x y = x + y
     where  -- I just left this where here by accident

   g x = ...

parses as

   f x y = x + y
     where { -- I just left this empty where here by accident

   g x = ...
   }

and

   instance Exception Foo where
   instance Exception Bar

parses as

   instance Exception Foo where {
     instance Exception Bar
   }


That is, layout contexts that should really be empty end up surprisingly
swallowing the rest of the file.

Cheers,
        Simon

> It would then correctly translate the above.  This of course implies that any
> code that requires the original translation (i.e., where the last of multiple
> enclosing blocks should be an empty block) would no longer work.
>
> Is any code actually relying on this though?  It seems like a pretty esoteric
> corner case.  If not, my vote would be to relax this rule and go with '\'
> being a layout hearld with full case style matching (i.e., guards too).
>
> Cheers!  -Tyson
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users