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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

Tyson Whitehead
On July 6, 2012 05:25:15 Simon Marlow wrote:
> > Why not just let enclosed scopes be less indented than their outer ones?

Let me be entirely clear about what I was thinking about.  The third case for
the layout mapping in Section 9.3 of the report is

  L ({n}:ts) (m:ms) = { : (L ts (n:m:ms)) if n > m

This function takes a possibly layout sensitive token stream augmented with
'{n}' for the indentation level of the first token following a grouping token
that doesn't have a '{' and '<n>' for the indentation level of first tokens
after newlines that are not already augmented with '{n}'.  The 'L' functions
maps this to a non-augmented non-layout sensitive stream.

The first argument is the augmented layout stream and the current stack of
indentations for any groupings in effect.  The rule above inserts a '{' if
there isn't one after a grouping token and the next token is at a deeper level
then the current grouping level.  I was proposing to make it always fire on
indentation (i.e., allow enclosing scopes to be less indented).

  L ({n}:ts) (m:ms) = { : (L ts (n:m:ms)) if n > 0

The rest of the '{' insertion rules are for starting the first '{' on any
indentation after a grouping token not followed by a '{' and for inserting a
'{}' in all other cases.

  L ({n}:ts) [] = { : (L ts [n]) if n > 0
  L ({n}:ts) ms = { : } : (L (<n>:ts) ms)

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

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

These would be okay under the above so long as the following lines are not
indented.  The issue only arises with nested ones

f x = ...
  where
    g y = ...
      where
    h y = ...

Now the h gets sucked into the where clause as it is empty and nested.  Using
the metric of what would most people expect, I agree the above is not ideal
(although I would hope empty nested where clauses not really in common use).

By this same metric though, I also think things like

where f x = do
  stmt1
  stmt2

mask $ let x = do
  stmt1
  stmt2

being parsed to

where { f x = do {}
} stmt1
   stmt2

mask $ let { x = do {}
  stmt1
  stmt2
}

is also not ideal.  The real underlying issue in both these cases and changing
'\' to a group token seems to be what happens on single lines with multiple
groupings when the last grouping actually starts on a newline indented further
than the proceeding line.

Currently it depends on the depth of this new level of indentation relative to
all the groupings started on that line.  I think most people would expect it
to just apply to the last grouping though.  That is

where { f x = do {
  stmt1
  stmt2
} }

mask $ let { x = do {
  stmt1
  stmt2
} }

The rule in this case would be that if the grouping began on a newline that is
idented farther then the previous line, the grouping is assocated with the
grouping token and when it closes, it closes all those deeper than itself.

Cheers!  -Tyson

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help

M Farkas-Dyck
In reply to this post by Mikhail Vorozhtsov
On 05/07/2012, Mikhail Vorozhtsov <[hidden email]> 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!
>

+1 for "\ of" multi-clause lambdas

It looks like binding "of" to me, which it ain't, but it is nicely brief...

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help

Chris Smith-31

Whoops, my earlier answer forgot to copy mailing lists... I would love to see \of, but I really don't think this is important enough to make case sometimes introduce layout and other times not.  If it's going to obfuscate the lexical syntax like that, I'd rather just stick with \x->case x of.

On Jul 6, 2012 3:15 PM, "Strake" <[hidden email]> wrote:
On 05/07/2012, Mikhail Vorozhtsov <[hidden email]> 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!
>

+1 for "\ of" multi-clause lambdas

It looks like binding "of" to me, which it ain't, but it is nicely brief...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Tyson Whitehead
In reply to this post by Tyson Whitehead
On July 6, 2012 11:49:23 Tyson Whitehead wrote:

> Currently it depends on the depth of this new level of indentation relative
> to all the groupings started on that line.  I think most people would
> expect it to just apply to the last grouping though.  That is
>
> where { f x = do {
>   stmt1
>   stmt2
> } }
>
> mask $ let { x = do {
>   stmt1
>   stmt2
> } }
>
> The rule in this case would be that if the grouping began on a newline that
> is idented farther then the previous line, the grouping is assocated with
> the grouping token and when it closes, it closes all those deeper than
> itself.

I've thought some more about this and it seems to me that there are two ways
people might intuitively think about doing grouping via indentation.

1 - the first item is on the same line and subsequent ones are lined up with it

  do stmt1
     stmt2

2 - the first item is on a new line and subsequent ones are lined up with it.

  do
    stmt1
    stmt2

The current layout engine is targeted at (1).  It appears to do (2), but it is
not really reliable as things start to go south if the first line happened to
open more than one grouping (precisely the problem that make '\' a group token
would introduce in codes).  For an example, consider

  let greet name = do
    putStr "hello "
    putStrLn name
  in f "world"

It currently translates into

  let { greet name = do {} } putStr "hello " putStrLn name in f "world"

This results in an unituituve "Empty 'do' construct" error message.

I propose we detected (2) and make it work too.  That is, if the line ends
with a grouping construct and the next line is indented relative to that line,
then assume we really don't want '{}' and instead always start grouping (even
if it isn't indented further than other possible groupings also started).

In other words, translate the above into

  let { greet name = do {
    putStr "hello";
    putStrLn name
  }} in f "world"

This would then correctly handle the problamatic case raised in wiki where

  mask $ \restore -> do
    stmt1
    stmt2

is in translated into

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

under the current rules if '\' is made a grouping token.

The very limited scope of this (i.e., it would only apply to lines that end
with a grouping construct where the next line is indented further than that
line) should also address Simon's concerns regarding things like

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

   g x = ...

and

   instance Exception Foo where
   instance Exception Bar

Cheers!  -Tyson

PS:  To be fully precise, the modified layout decoder in 9.3 would be

  L (<n>:ts)     i (m:ms) = ; : (L ts n (m:ms))   if m = n
                          = } : (L (<n>:ts) n ms) if n < m
  L (<n>:ts)     i ms     = L ts n ms
  L ({n}:<n>:ts) i ms     = { : (L ts n (n:ms))   if n > i (new rule)
  L ({n}:ts)     i (m:ms) = { : (L ts i (n:m:ms)) if n > m  (Note 1)
  L ({n}:ts)     i []     = { : (L ts i [n])      if n > 0  (Note 1)
  L ({n}:ts)     i ms     = { : } : (L (<n>:ts) i ms)       (Note 2)
  L (}:ts)       i (0:ms) = } : (L ts i ms)                 (Note 3)
  L (}:ts)       i ms     = parse-error                     (Note 3)
  L ({:ts)       i ms     = { : (L ts i (0:ms))             (Note 4)
  L (t:ts)       i (m:ms) = } : (L (t:ts) i ms)   if m /= 0 and parse-error(t)
(Note 5)
  L (t:ts)       i ms     = t : (L ts i ms)
  L []           i []     = []
  L []           i (m:ms) = } : L [] i ms         if m /= 0 (Note 6)

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

As before, the function 'L' maps a layout-sensitive augmented token stream to
a non-layout-sensitive token stream, where the augmented token stream includes
'<n>' and '{n}' to, respectively, give the indentation level of the first token
on a new line and that following a grouping token not followed by '{'.

This time though, we allow the '{n}' '<n>' sequence (before it was supressed
to just '{n}').  We also add a new state variable 'i' to track the indentation
of the  current line.  The new rule now opens a grouping over a newline so
long as the indentation is greater than the current line.

Upon a less indented line, it will then close all currently open groups with
an indentation less than the new line.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Jonas Almström Duregård-2
Couldn't we use \\ for multi-case lambdas with layout?

If not, these are my preferences in order (all are single argument versions):
1: Omission: "case of". There seems to be some support for this but it
was not included in the summary.
2: Omission with clarification: "\case of"
3: "\of"  - but I think this is a little weird. It's nice to have
short keywords but not at the expense of intuition. The goal here is
to drop the variable name not the case keyword, right?

Regards,
Jonas

On 7 July 2012 06:08, Tyson Whitehead <[hidden email]> wrote:

> On July 6, 2012 11:49:23 Tyson Whitehead wrote:
>> Currently it depends on the depth of this new level of indentation relative
>> to all the groupings started on that line.  I think most people would
>> expect it to just apply to the last grouping though.  That is
>>
>> where { f x = do {
>>   stmt1
>>   stmt2
>> } }
>>
>> mask $ let { x = do {
>>   stmt1
>>   stmt2
>> } }
>>
>> The rule in this case would be that if the grouping began on a newline that
>> is idented farther then the previous line, the grouping is assocated with
>> the grouping token and when it closes, it closes all those deeper than
>> itself.
>
> I've thought some more about this and it seems to me that there are two ways
> people might intuitively think about doing grouping via indentation.
>
> 1 - the first item is on the same line and subsequent ones are lined up with it
>
>   do stmt1
>      stmt2
>
> 2 - the first item is on a new line and subsequent ones are lined up with it.
>
>   do
>     stmt1
>     stmt2
>
> The current layout engine is targeted at (1).  It appears to do (2), but it is
> not really reliable as things start to go south if the first line happened to
> open more than one grouping (precisely the problem that make '\' a group token
> would introduce in codes).  For an example, consider
>
>   let greet name = do
>     putStr "hello "
>     putStrLn name
>   in f "world"
>
> It currently translates into
>
>   let { greet name = do {} } putStr "hello " putStrLn name in f "world"
>
> This results in an unituituve "Empty 'do' construct" error message.
>
> I propose we detected (2) and make it work too.  That is, if the line ends
> with a grouping construct and the next line is indented relative to that line,
> then assume we really don't want '{}' and instead always start grouping (even
> if it isn't indented further than other possible groupings also started).
>
> In other words, translate the above into
>
>   let { greet name = do {
>     putStr "hello";
>     putStrLn name
>   }} in f "world"
>
> This would then correctly handle the problamatic case raised in wiki where
>
>   mask $ \restore -> do
>     stmt1
>     stmt2
>
> is in translated into
>
>   mask $ \ { restore -> do {} } stmt1 stmt2
>
> under the current rules if '\' is made a grouping token.
>
> The very limited scope of this (i.e., it would only apply to lines that end
> with a grouping construct where the next line is indented further than that
> line) should also address Simon's concerns regarding things like
>
>    f x y = x + y
>      where  -- I just left this where here by accident
>
>    g x = ...
>
> and
>
>    instance Exception Foo where
>    instance Exception Bar
>
> Cheers!  -Tyson
>
> PS:  To be fully precise, the modified layout decoder in 9.3 would be
>
>   L (<n>:ts)     i (m:ms) = ; : (L ts n (m:ms))   if m = n
>                           = } : (L (<n>:ts) n ms) if n < m
>   L (<n>:ts)     i ms     = L ts n ms
>   L ({n}:<n>:ts) i ms     = { : (L ts n (n:ms))   if n > i (new rule)
>   L ({n}:ts)     i (m:ms) = { : (L ts i (n:m:ms)) if n > m  (Note 1)
>   L ({n}:ts)     i []     = { : (L ts i [n])      if n > 0  (Note 1)
>   L ({n}:ts)     i ms     = { : } : (L (<n>:ts) i ms)       (Note 2)
>   L (}:ts)       i (0:ms) = } : (L ts i ms)                 (Note 3)
>   L (}:ts)       i ms     = parse-error                     (Note 3)
>   L ({:ts)       i ms     = { : (L ts i (0:ms))             (Note 4)
>   L (t:ts)       i (m:ms) = } : (L (t:ts) i ms)   if m /= 0 and parse-error(t)
> (Note 5)
>   L (t:ts)       i ms     = t : (L ts i ms)
>   L []           i []     = []
>   L []           i (m:ms) = } : L [] i ms         if m /= 0 (Note 6)
>
>   http://www.haskell.org/onlinereport/syntax-iso.html
>
> As before, the function 'L' maps a layout-sensitive augmented token stream to
> a non-layout-sensitive token stream, where the augmented token stream includes
> '<n>' and '{n}' to, respectively, give the indentation level of the first token
> on a new line and that following a grouping token not followed by '{'.
>
> This time though, we allow the '{n}' '<n>' sequence (before it was supressed
> to just '{n}').  We also add a new state variable 'i' to track the indentation
> of the  current line.  The new rule now opens a grouping over a newline so
> long as the indentation is greater than the current line.
>
> Upon a less indented line, it will then close all currently open groups with
> an indentation less than the new line.
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

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

wagnerdm@seas.upenn.edu
Quoting Jonas Almström Duregård <[hidden email]>:

> Couldn't we use \\ for multi-case lambdas with layout?

Actually, \\ is a valid (infix) function name... and the base library  
includes one in Data.List. That name is copied in several other  
container interfaces, as well.

~d

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

M Farkas-Dyck
In reply to this post by Jonas Almström Duregård-2
On 07/07/2012, Jonas Almström Duregård <[hidden email]> wrote:

> Couldn't we use \\ for multi-case lambdas with layout?
>
> If not, these are my preferences in order (all are single argument
> versions):
> 1: Omission: "case of". There seems to be some support for this but it
> was not included in the summary.
> 2: Omission with clarification: "\case of"
> 3: "\of"  - but I think this is a little weird. It's nice to have
> short keywords but not at the expense of intuition. The goal here is
> to drop the variable name not the case keyword, right?
>
> Regards,
> Jonas

Well, since this is now suddenly a ranked-choice election, I shall
re-cast my vote:

1. "case of"
2. "\ of"

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Tyson Whitehead
In reply to this post by Tyson Whitehead
On July 7, 2012 00:08:26 Tyson Whitehead wrote:

> The very limited scope of this (i.e., it would only apply to lines that end
> with a grouping construct where the next line is indented further than that
> line) should also address Simon's concerns regarding things like
>
>    f x y = x + y
>      where  -- I just left this where here by accident
>
>    g x = ...
>
> and
>
>    instance Exception Foo where
>    instance Exception Bar

The only thing that would still break is a line that starts multiple
groupings, where the last is a valid empty groups (i.e., let or where) and the
next line is further indented then the previous line.

The least grotesque/contrived examples I could think of are

  do let
     stmt1
     stmt2

and

  let f x = ... where
      g y = ...

Cheers!  -Tyson

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Dan Doel
In reply to this post by Edward Kmett-2
If we're voting....

I think \of is all right, and multi-argument case could be handy,
which rules out using 'case of' for lambda case, because it's the
syntax for a 0-argument case:

    case of
      | guard1 -> ...
      | guard2 -> ...

Then multi-argument lambda case could use the comma syntax of
multi-argument case.

One thing I don't think makes sense in combination is \of with
0-arguments, since any desugaring of that is not going to involve and
actual lambda expression.

-- Dan

On Thu, Jul 5, 2012 at 5:04 PM, Edward Kmett <[hidden email]> wrote:

> 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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by Tyson Whitehead
On 07/07/2012 05:08, Tyson Whitehead wrote:

> PS:  To be fully precise, the modified layout decoder in 9.3 would be
>
>    L (<n>:ts)     i (m:ms) = ; : (L ts n (m:ms))   if m = n
>                            = } : (L (<n>:ts) n ms) if n < m
>    L (<n>:ts)     i ms     = L ts n ms
>    L ({n}:<n>:ts) i ms     = { : (L ts n (n:ms))   if n > i (new rule)
>    L ({n}:ts)     i (m:ms) = { : (L ts i (n:m:ms)) if n > m  (Note 1)
>    L ({n}:ts)     i []     = { : (L ts i [n])      if n > 0  (Note 1)
>    L ({n}:ts)     i ms     = { : } : (L (<n>:ts) i ms)       (Note 2)
>    L (}:ts)       i (0:ms) = } : (L ts i ms)                 (Note 3)
>    L (}:ts)       i ms     = parse-error                     (Note 3)
>    L ({:ts)       i ms     = { : (L ts i (0:ms))             (Note 4)
>    L (t:ts)       i (m:ms) = } : (L (t:ts) i ms)   if m /= 0 and parse-error(t)
> (Note 5)
>    L (t:ts)       i ms     = t : (L ts i ms)
>    L []           i []     = []
>    L []           i (m:ms) = } : L [] i ms         if m /= 0 (Note 6)
>
>    http://www.haskell.org/onlinereport/syntax-iso.html
>
> As before, the function 'L' maps a layout-sensitive augmented token stream to
> a non-layout-sensitive token stream, where the augmented token stream includes
> '<n>' and '{n}' to, respectively, give the indentation level of the first token
> on a new line and that following a grouping token not followed by '{'.
>
> This time though, we allow the '{n}' '<n>' sequence (before it was supressed
> to just '{n}').  We also add a new state variable 'i' to track the indentation
> of the  current line.  The new rule now opens a grouping over a newline so
> long as the indentation is greater than the current line.
>
> Upon a less indented line, it will then close all currently open groups with
> an indentation less than the new line.

It's a little hard to evaluate this without trying it for real to see
whether it breaks any existing code.  However, unless there are very
strong reasons to do so, I would argue against making the layout rule
*more* complicated.  I find the current rule behaves quite intuitively,
even though its description is hard to understand and it is virtually
impossible to implement.

I now think '\' is too quiet to introduce a new layout context.  The
pressing need is really for a combination of '\' and 'case', that is
single-argument so that we don't have to write parentheses.  I think
'\case' does the job perfectly.  If you want a multi-clause
multi-argument function, then give it a name.

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by M Farkas-Dyck
On 07/07/2012 16:07, Strake wrote:

> On 07/07/2012, Jonas Almström Duregård <[hidden email]> wrote:
>> Couldn't we use \\ for multi-case lambdas with layout?
>>
>> If not, these are my preferences in order (all are single argument
>> versions):
>> 1: Omission: "case of". There seems to be some support for this but it
>> was not included in the summary.
>> 2: Omission with clarification: "\case of"
>> 3: "\of"  - but I think this is a little weird. It's nice to have
>> short keywords but not at the expense of intuition. The goal here is
>> to drop the variable name not the case keyword, right?
>>
>> Regards,
>> Jonas
>
> Well, since this is now suddenly a ranked-choice election, I shall
> re-cast my vote:

I think some misunderstanding has crept in - we're not planning to count
votes or anything here.  If you have new suggestions or know of reasons
for/against existing proposals then please post, otherwise there's no
need to post just to express your personal preference.

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Mikhail Vorozhtsov
Hi Simon.

On 07/09/2012 08:23 PM, Simon Marlow wrote:

> On 07/07/2012 16:07, Strake wrote:
>> On 07/07/2012, Jonas Almström Duregård <[hidden email]>
>> wrote:
>>> Couldn't we use \\ for multi-case lambdas with layout?
>>>
>>> If not, these are my preferences in order (all are single argument
>>> versions):
>>> 1: Omission: "case of". There seems to be some support for this but it
>>> was not included in the summary.
>>> 2: Omission with clarification: "\case of"
>>> 3: "\of"  - but I think this is a little weird. It's nice to have
>>> short keywords but not at the expense of intuition. The goal here is
>>> to drop the variable name not the case keyword, right?
>>>
>>> Regards,
>>> Jonas
>>
>> Well, since this is now suddenly a ranked-choice election, I shall
>> re-cast my vote:
>
> I think some misunderstanding has crept in - we're not planning to count
> votes or anything here.  If you have new suggestions or know of reasons
> for/against existing proposals then please post, otherwise there's no
> need to post just to express your personal preference.
Could you express your opinion on the case "comma sugar", i.e.

case x, y of
   P1, P2 -> ...
   P3, P4 -> ...

as sugar for

case (# x, y #) of
   (# P1, P2 #) -> ...
   (# P3, P4 #) -> ...

and respectively

\case
   P1, P2 -> ...
   P3, P4 -> ...

as sugar for

\x y -> case x, y of
   P1, P2 -> ...
   P3, P4 -> ...

?

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:

> Hi Simon.
>
> On 07/09/2012 08:23 PM, Simon Marlow wrote:
>> On 07/07/2012 16:07, Strake wrote:
>>> On 07/07/2012, Jonas Almström Duregård <[hidden email]>
>>> wrote:
>>>> Couldn't we use \\ for multi-case lambdas with layout?
>>>>
>>>> If not, these are my preferences in order (all are single argument
>>>> versions):
>>>> 1: Omission: "case of". There seems to be some support for this but it
>>>> was not included in the summary.
>>>> 2: Omission with clarification: "\case of"
>>>> 3: "\of"  - but I think this is a little weird. It's nice to have
>>>> short keywords but not at the expense of intuition. The goal here is
>>>> to drop the variable name not the case keyword, right?
>>>>
>>>> Regards,
>>>> Jonas
>>>
>>> Well, since this is now suddenly a ranked-choice election, I shall
>>> re-cast my vote:
>>
>> I think some misunderstanding has crept in - we're not planning to count
>> votes or anything here.  If you have new suggestions or know of reasons
>> for/against existing proposals then please post, otherwise there's no
>> need to post just to express your personal preference.
> Could you express your opinion on the case "comma sugar", i.e.
>
> case x, y of
>    P1, P2 -> ...
>    P3, P4 -> ...
>
> as sugar for
>
> case (# x, y #) of
>    (# P1, P2 #) -> ...
>    (# P3, P4 #) -> ...

I like this.

> and respectively
>
> \case
>    P1, P2 -> ...
>    P3, P4 -> ...
>
> as sugar for
>
> \x y -> case x, y of
>    P1, P2 -> ...
>    P3, P4 -> ...

That looks a bit strange to me, because I would expect

  \case
     P1, P2 -> ...
     P3, P4 -> ...

to be a function of type (# a, b #) -> ...

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Twan van Laarhoven
In reply to this post by Simon Marlow-7
On 09/07/12 14:44, Simon Marlow wrote:
> I now think '\' is too quiet to introduce a new layout context.  The pressing
> need is really for a combination of '\' and 'case', that is single-argument so
> that we don't have to write parentheses.  I think '\case' does the job
> perfectly.  If you want a multi-clause multi-argument function, then give it a
> name.

There is an advantage here for "\of" in favor of "\case", namely that "of"
already introduces layout, while "case" does not.



Twan

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Mikhail Vorozhtsov
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:

> On 09/07/12 14:44, Simon Marlow wrote:
>> I now think '\' is too quiet to introduce a new layout context.  The
>> pressing
>> need is really for a combination of '\' and 'case', that is
>> single-argument so
>> that we don't have to write parentheses.  I think '\case' does the job
>> perfectly.  If you want a multi-clause multi-argument function, then
>> give it a
>> name.
>
> There is an advantage here for "\of" in favor of "\case", namely that
> "of" already introduces layout, while "case" does not.
Do you think that adding "\" + "case" as a layout herald would
complicate the language spec and/or confuse users? Because it certainly
does not complicate the implementation (there is a patch for \case
already). IMO \case is more descriptive, "of" is just a preposition
after all.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Jeltsch-2
In reply to this post by Tyson Whitehead
Am Samstag, den 07.07.2012, 00:08 -0400 schrieb Tyson Whitehead:

> I've thought some more about this and it seems to me that there are
> two ways people might intuitively think about doing grouping via
> indentation.
>
> 1 - the first item is on the same line and subsequent ones are lined
>     up with it
>
>   do stmt1
>      stmt2
>
> 2 - the first item is on a new line and subsequent ones are lined up
>     with it.
>
>   do
>     stmt1
>     stmt2
>
> The current layout engine is targeted at (1).  It appears to do (2),
> but it is not really reliable as things start to go south if the first
> line happened to open more than one grouping (precisely the problem
> that make '\' a group token would introduce in codes).  For an
> example, consider
>
>   let greet name = do
>     putStr "hello "
>     putStrLn name
>   in f "world"
>
> It currently translates into
>
>   let { greet name = do {} } putStr "hello " putStrLn name in f "world"
>
> This results in an unituituve "Empty 'do' construct" error message.

The problem is that your example is not consistently using (2). A pure
(2)-example would look like this:

    let
        greet name = do
            putStr "hello "
            putStrLn name
    in greet "world"

And this works. :-)

Best wishes,
Wolfgang



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Chris Smith-31
In reply to this post by Twan van Laarhoven
Right, it seems to me that there are basically three reasonable proposals here:

1. "\ of" with multiple arguments.  This is consistent with existing
layout, and seems like a nice generalization of lambda syntax.
2. "case of" with a single argument.  This is consistent with existing
layout, and seems like a nice generalization of sections.
3. "\" introducing layout, possibly with changes to layout rules.  A
much more intrusive change, but it does have a nice efficiency to it.

Either of the first two would be fine.  For that matter, they could
even *both* be done -- with #2 being a shorthand to avoid parentheses
-- without seeming too redundant to me.  I tend to see the third
option as too intrusive and dangerous, but I can see the argument for
doing it.  Given that we have these three options, I really don't see
the benefit to "\ case" or similar ideas, which complicate layout
rules for little reason, and mix syntax in such a way that it's
difficult for me at least to even predict whether parentheses are
required.

On Mon, Jul 9, 2012 at 8:52 AM, Twan van Laarhoven <[hidden email]> wrote:

> On 09/07/12 14:44, Simon Marlow wrote:
>>
>> I now think '\' is too quiet to introduce a new layout context.  The
>> pressing
>> need is really for a combination of '\' and 'case', that is
>> single-argument so
>> that we don't have to write parentheses.  I think '\case' does the job
>> perfectly.  If you want a multi-clause multi-argument function, then give
>> it a
>> name.
>
>
> There is an advantage here for "\of" in favor of "\case", namely that "of"
> already introduces layout, while "case" does not.
>
>
>
> 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
Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Jeltsch-2
In reply to this post by Mikhail Vorozhtsov
Am Montag, den 09.07.2012, 21:04 +0700 schrieb Mikhail Vorozhtsov:

> Could you express your opinion on the case "comma sugar", i.e.
>
> case x, y of
>    P1, P2 -> ...
>    P3, P4 -> ...
>
> as sugar for
>
> case (# x, y #) of
>    (# P1, P2 #) -> ...
>    (# P3, P4 #) -> ...
>
> and respectively
>
> \case
>    P1, P2 -> ...
>    P3, P4 -> ...
>
> as sugar for
>
> \x y -> case x, y of
>    P1, P2 -> ...
>    P3, P4 -> ...
>
> ?

Although I wasn’t asked, I want to express my opinion. I think, the use
of the comma is strange. When declaring functions with multiple
arguments, we don’t have commas:

    f Nothing  y = y
    f (Just x) y = x

In lambda expressions for multi-argument functions, we also don’t have
commas:

    \x y -> x + y

Why should we have them when using a case-lambda expression for a
multi-argument function?

Best wishes,
Wolfgang


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Mikhail Vorozhtsov
In reply to this post by Simon Marlow-7
On 07/09/2012 09:49 PM, Simon Marlow wrote:

> On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:
>> Hi Simon.
>>
>> On 07/09/2012 08:23 PM, Simon Marlow wrote:
>>> On 07/07/2012 16:07, Strake wrote:
>>>> On 07/07/2012, Jonas Almström Duregård <[hidden email]>
>>>> wrote:
>>>>> Couldn't we use \\ for multi-case lambdas with layout?
>>>>>
>>>>> If not, these are my preferences in order (all are single argument
>>>>> versions):
>>>>> 1: Omission: "case of". There seems to be some support for this but it
>>>>> was not included in the summary.
>>>>> 2: Omission with clarification: "\case of"
>>>>> 3: "\of"  - but I think this is a little weird. It's nice to have
>>>>> short keywords but not at the expense of intuition. The goal here is
>>>>> to drop the variable name not the case keyword, right?
>>>>>
>>>>> Regards,
>>>>> Jonas
>>>>
>>>> Well, since this is now suddenly a ranked-choice election, I shall
>>>> re-cast my vote:
>>>
>>> I think some misunderstanding has crept in - we're not planning to count
>>> votes or anything here.  If you have new suggestions or know of reasons
>>> for/against existing proposals then please post, otherwise there's no
>>> need to post just to express your personal preference.
>> Could you express your opinion on the case "comma sugar", i.e.
>>
>> case x, y of
>>    P1, P2 -> ...
>>    P3, P4 -> ...
>>
>> as sugar for
>>
>> case (# x, y #) of
>>    (# P1, P2 #) -> ...
>>    (# P3, P4 #) -> ...
>
> I like this.
Good!

>
>> and respectively
>>
>> \case
>>    P1, P2 -> ...
>>    P3, P4 -> ...
>>
>> as sugar for
>>
>> \x y -> case x, y of
>>    P1, P2 -> ...
>>    P3, P4 -> ...
>
> That looks a bit strange to me, because I would expect
>
>   \case
>      P1, P2 -> ...
>      P3, P4 -> ...
>
> to be a function of type (# a, b #) -> ...
Hm, maybe I put it slightly wrong. Desugaring is really only a means of
implementation here. Would you still expect tuples for \case if you
didn't see the way `case x, y of ...` was implemented (or thought that
it is a primitive construct)?

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Jeltsch-2
In reply to this post by Chris Smith-31
Am Montag, den 09.07.2012, 10:20 -0600 schrieb Chris Smith:
> Right, it seems to me that there are basically three reasonable proposals here:
>
> 1. "\ of" with multiple arguments.  This is consistent with existing
> layout, and seems like a nice generalization of lambda syntax.
> 2. "case of" with a single argument.  This is consistent with existing
> layout, and seems like a nice generalization of sections.
> 3. "\" introducing layout, possibly with changes to layout rules.  A
> much more intrusive change, but it does have a nice efficiency to it.

I strongly favor a solution where lambda-case expressions start with \,
because this can be generalized to proc expressions from arrow syntax
simply by replacing the \ with proc.

Take, for example, the following function definition:

    f (Left  x) = g x
    f (Right y) = h y

Now, let’s make an arrow version of it:

    f = proc e -> case e of
            Left  x -> g -< x
            Right y -> h -< y

It would be great if we could write something like this instead:

    f = proc of
            Left  x -> g -< x
            Right y -> h -< y

This is not just a contrived issue. In my current work on Grapefruit,
I encounter this situation quite often, and I would love to get rid of
the extra overhead I have to deal with now.

Best wishes,
Wolfgang


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