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

Mikhail Vorozhtsov
On 07/09/2012 11:22 PM, Wolfgang Jeltsch wrote:

> 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?
The trick here is to not start with functions, but with
case-expressions. If we introduce "multi-place" case-expressions not as
a sugar, but as an extension of regular case-expressions (which may be
/implemented/ as a sugar under the hood), then it would be only natural
for pattern syntax used with "case" to transfer to lambda-case, as it
already does in the current single-argument proposals (no parentheses
around patterns). lambda-CASE, not LAMBDA-case (that's why I prefer
\case to \of - it says clearly "hey, it's a case expression, expect
stuff to be casy").

_______________________________________________
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

Bardur Arantsson-2
In reply to this post by Mikhail Vorozhtsov
On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:

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

Just being anal here, but: The existence of a patch to implement X does
not mean that X doesn't complicate the implemenatation.

... as you were.


_______________________________________________
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

Wolfram Kahl
In reply to this post by Wolfgang Jeltsch-2
On Mon, Jul 09, 2012 at 07:22:30PM +0300, Wolfgang Jeltsch wrote:

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

A variant of this question is easy to answer:
multi-case-multi-argument function expressions are conceptually obtained
as generalisation of sets of case bindings (the part after the ``of'')
instead of as a generalisation of lambda expressions.

This leads me to a first quick shot:

  Proposal 1: ``caseof'':

     Introduce a new layout keyword ``caseof'' to delimit (via layout or braces)
     the case bindings, producing the function that currently would be
     \ x -> case x of ...    (with fresh x).


Multi-case-multi-argument function definitions are currently translated into
multi-case-single-argument case expressions, with the arguments collected together
into tuples --- this might provide motivation for the commas.

This leads me to a second quick shot:

  Proposal 2: ``no-multiple-argument-case'':

    Make no further changes to the case bindings syntax.
    Programmers who want multiple arguments can put them into tuples
    and curry the whole caseof construct, which is reasonably cheap syntactically:

      zip = curry $ caseof
        ([]      , ys    ) -> []
        (xs      , []    ) -> []
        (x : xs  , y : ys) -> (x , y) : zip xs ys

   This has the advantage that no new rules need to be added
   to syntax or semantics.


Side note (and shameless plug): The above is partially inspired by my work
on the pattern matching calculus (PMC) where groups of case bindings
form the second syntactic category of ``matchings'' (besides expressions).
``caseof'' then corresponds to the wrapping {| m |}
that turns a matching into an expression,
and Haskell's sequence of case bindings would be mapped to the monoid
of matchings with with empty matching as unit and matching alternative
as composition.

PMC includes two additional features that allow equational reasoning
with matchings (case binding groups):

  Argument supply:
    Applying a matching to an argument without first converting
    the matching into an expression.

    This feature can be seen as a generalisation of pattern guards.

  Nestable matching construction:
    Individual cases in PMC are of shape ``p -> m''
    with a matching right-hand side instead of an expression``p -> e'' in Haskell.

Nestable matching construction allows construction of multiple-argument pattern matching functions
with more liberal shapes than the strict matrix shape required for function definitions,
but with a different semantics.

That more liberal shape can already be achieved with the tuple scheme of proposal 2 above:

  f = curry $ curry $ caseof
    (p        , [])      -> ...
    ((xs, []) , z : zs)  -> ...
    _                    -> ...

and
      zip = curry $ caseof
        (x : xs , y : ys)  -> (x , y) : zip xs ys
        _                  -> []


Integrating argument supply and nestable matching construction into Haskell
would be a more far-reaching change --- an ``easy'' attempt at nestable
matching construction alone would turn the -> of case bindings into a
layout keyword, and insert conversion of expressions into
zero-argument matchings (``return'') automagically:

  zip = caseof
    [] -> []
    x : xs ->
       [] -> []
       y : ys -> (x , y) : zip xs ys

The important aspect of considering the part after -> as a matching
instead of as an expression is fall-through --- the nested patterns
act somewhat like pattern guards:

  zip = caseof
    x : xs -> y : ys -> (x , y) : zip xs ys
    _   ->   _  -> []

The two alternatives in this last example are intentionally not aligned
to emphasise the fact that the two 2-argument matchings are constructed
completely indepnedent from each other.

Automagical insertion of conversion of expressions into zero-argument
matchings depends on having no expressions that can legally be parsed
as matchings. With what I sketched above, this might actually work,
but I cannot claim that I have fully thought this through.
If it can be made to work, it could be called

  Proposal 3: ``nestable case bindings''.



Generalising pattern guard syntax into argument supply requires a second
syntactic construct that contains a group of case bindings;
most easily this would be another layout keyword, say ``into''
(in the PMC papers, this is $\righttriangle$;
 better keywords would be welcome; I guess ``|>'' is not a good idea...):

Pattern guards are of shape ``pat <- arg'' with the argument to the right,
as in SPJ's ``clunky'':

  clunky env var1 var2
    | Just val1 <- lookup env var1
    , Just val2 <- lookup env var2
    = val1 + val2
  ...other equations for clunky...

For argument supply and ``into'' we use the opposite sequence,
``arg  into  pat'', and clunky could then become:

  clunky = caseof
    env ->
      var1 ->
        var2 ->
          lookup env var1  into
            Just val1 ->
              lookup env var2  into
                Just val2 -> val1 + val2
    ... other case bindings for clunky ....

(This runs into similar nested layout issues as discussed recently;
 if we were to change the layout rule (perhaps only for the new keywords)
 to not apply if the next token is separated from the layout keyword
 by only a single space, we could turn this into a more compact shape:

  clunky = caseof
    env -> var1 -> var2 -> lookup env var1  into Just val1
                        -> lookup env var2  into Just val2 -> val1 + val2
    ... other case bindings for clunky ....

 (The alignment of the two lookups and their preceding -> is irrelevant here.)
)

``into'' would generalise pattern guards by allowing the same expression
to be matched against different patterns and still enable fall-through:

  f = caseof
    [x] -> g x  into  []         -> []
                      a : b : bs -> (a, b) : h bs
    ... other cases, including g returning a singleton ...


This could be:

  Proposal 4: ``case-group argument supply'' or ``generalised pattern guards''



Best wishes,

Wolfram


---------------------------------------------


@InProceedings{Kahl-2004a,
  author = {Wolfram Kahl},
  title = {Basic Pattern Matching Calculi: A Fresh View on Matching Failure},
  crossref =  {FLOPS2004},
  pages = {276--290},
  DOI = {10.1007/978-3-540-24754-8_20},
  SpringerURL = {http://www.springerlink.com/content/3jet4qgw1q2nu0a8/},
  abstract = {We propose pattern matching calculi as a refinement
      of $\lambda$-calculus that integrates mechanisms appropriate for
      fine-grained modelling of non-strict pattern matching.

      Compared with the functional rewriting strategy
      usually employed to define the operational semantics of
      pattern matching in non-strict functional programming languages
      like Haskell or Clean, our pattern matching calculi
      achieve the same effects using simpler and more local rules.

      The main device is to embed into expressions
      the separate syntactic category of matchings;
      the resulting language naturally encompasses
      pattern guards and Boolean guards as special cases.

      By allowing a confluent reduction system and a normalising strategy,
      these pattern matching calculi provide a new basis for
      operational semantics of non-strict programming languages
      and also for implementations.}
}

@InProceedings{Kahl-Carette-Ji-2006a,
  author = {Wolfram Kahl and Jacques Carette and Xiaoheng Ji},
  title = {Bimonadic Semantics for Basic Pattern Matching Calculi},
  crossref =  {MPC2006},
  pages = {253--273},
  DOI = {10.1007/11783596_16},
  SpringerURL = {http://www.springerlink.com/content/2715070606u63648/}
}

_______________________________________________
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 Bardur Arantsson-2
On 07/10/2012 01:09 AM, Bardur Arantsson wrote:

> On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:
>> 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).
>
> Just being anal here, but: The existence of a patch to implement X does
> not mean that X doesn't complicate the implemenatation.
In general, yes. But that particular patch[1] uses ~20 lines of pretty
straightforward (if I'm allowed to say that about the code I wrote
myself) code to handle layout. Which in my book is not complex at all.

[1]
http://hackage.haskell.org/trac/ghc/attachment/ticket/4359/one-arg-lambda-case.patch

_______________________________________________
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 Peyton Jones
In reply to this post by Wolfgang Jeltsch-2
| 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

I don't think I was aware of the proc part.

I think it's very helpful if lambdas start with a lambda, which to me suggests \case.  I'm not keen on \of; "case" says "case analysis" more clearly. But you presumably do not want \proc, because proc is the lambda. So that would leave use with "\case" and "proc of" as the two constructs.  Perhaps the lesser of the evils, but a bit inconsistent.

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
On 07/10/2012 01:53 PM, Simon Peyton-Jones wrote:

> | 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
>
> I don't think I was aware of the proc part.
>
> I think it's very helpful if lambdas start with a lambda, which to me suggests \case.  I'm not keen on \of; "case" says "case analysis" more clearly. But you presumably do not want \proc, because proc is the lambda. So that would leave use with "\case" and "proc of" as the two constructs.  Perhaps the lesser of the evils, but a bit inconsistent.
Why not use "proc case"?

_______________________________________________
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

Donn Cave-4
In reply to this post by Simon Peyton Jones
> I think it's very helpful if lambdas start with a lambda, which to
> me suggests \case.

I'd be interested to hear that explained a little further.  To me it isn't
obvious that `case of' is `a lambda', but it's obvious enough what it is
and how it works (or would work) - it's `case' with type a -> b instead
of just b ... and really the backslash just seems to confuse the issue.
I don't remember it from discussions of this proposal in years past.

> ... But you presumably do not want \proc, because proc is the lambda.

I also wondered if `case of' could be equally well generalized to
allow for `proc of', but I would certainly have no idea.

        Donn

_______________________________________________
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 Mikhail Vorozhtsov
On 09/07/2012 17:32, Mikhail Vorozhtsov wrote:

> On 07/09/2012 09:49 PM, Simon Marlow wrote:
>> On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:
>>> 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.

I think the desugaring is helpful - after all, most of the syntactic
sugar in Haskell is already specified by its desugaring.  And in this
case, the desugaring helps to explain why the multi-argument version is
strange.

 > 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)?

Yes, I still think it's strange.  We don't separate arguments by commas
anywhere else in the syntax; arguments are always separated by whitespace.

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 Mikhail Vorozhtsov
On 10/07/2012 07:33, Mikhail Vorozhtsov wrote:

> On 07/10/2012 01:09 AM, Bardur Arantsson wrote:
>> On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:
>>> 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).
>>
>> Just being anal here, but: The existence of a patch to implement X does
>> not mean that X doesn't complicate the implemenatation.
> In general, yes. But that particular patch[1] uses ~20 lines of pretty
> straightforward (if I'm allowed to say that about the code I wrote
> myself) code to handle layout. Which in my book is not complex at all.
>
> [1]
> http://hackage.haskell.org/trac/ghc/attachment/ticket/4359/one-arg-lambda-case.patch

The need to keep track of the previous token in the lexer *is* ugly though.

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

Wolfgang Jeltsch-2
In reply to this post by Simon Marlow-7
Am Dienstag, den 10.07.2012, 08:53 +0100 schrieb Simon Marlow:
> On 09/07/2012 17:32, Mikhail Vorozhtsov wrote:
> > 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)?
>
> Yes, I still think it's strange.  We don't separate arguments by
> commas anywhere else in the syntax; arguments are always separated by
> whitespace.

This is the point I wanted to make in my e-mail yesterday. Using a comma
here seems to be against established Haskell syntax conventions.

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

Wolfgang Jeltsch-2
In reply to this post by Simon Peyton Jones
Am Dienstag, den 10.07.2012, 06:53 +0000 schrieb Simon Peyton-Jones:

> > 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.
>
>  […]
>  
> I think it's very helpful if lambdas start with a lambda, which to me
> suggests \case.  I'm not keen on \of; "case" says "case analysis" more
> clearly. But you presumably do not want \proc, because proc is the
> lambda. So that would leave use with "\case" and "proc of" as the two
> constructs.  Perhaps the lesser of the evils, but a bit inconsistent.

If we use \case for functions, we should use proc case for arrows;
if we use \of for functions, we should use proc of for arrows.

By the way, is proc a layout herald already?

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
On Tue, Jul 10, 2012 at 5:53 AM, Wolfgang Jeltsch
<[hidden email]> wrote:
> If we use \case for functions, we should use proc case for arrows;
> if we use \of for functions, we should use proc of for arrows.
>
> By the way, is proc a layout herald already?

No, proc is not a layout herald.  The normal pattern is to use a do in
the command part of the proc syntax, so it's do that introduces the
layout.  So "proc of" would fit in cleanly as a way to do proc with
multiple patterns.  Or "proc case", but again that's just a really
ugly language wart, IMO uglier than just writing out the longhand
version of "proc x -> case x of".

--
Chris Smith

_______________________________________________
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

Iavor Diatchki
Hello,
I am late to the discussion and this is not entirely on topic, for which I apologize, but I like the multi-branch case syntax someone mentioned earlier:

Writing:

> case
>   | p1 -> e1
>   | p2 -> e2
>   | ...

desugars to:

> case () of
>   _ | p1 -> e2
>     | p2 -> e2
>     | ...

-Iavor
PS:  I think it also makes sense to use "if" instead of "case" for this.  Either way,  I find myself writing these kind of cases quite often, so having the sugar would be nice.


On Tue, Jul 10, 2012 at 8:55 AM, Chris Smith <[hidden email]> wrote:
On Tue, Jul 10, 2012 at 5:53 AM, Wolfgang Jeltsch
<[hidden email]> wrote:
> If we use \case for functions, we should use proc case for arrows;
> if we use \of for functions, we should use proc of for arrows.
>
> By the way, is proc a layout herald already?

No, proc is not a layout herald.  The normal pattern is to use a do in
the command part of the proc syntax, so it's do that introduces the
layout.  So "proc of" would fit in cleanly as a way to do proc with
multiple patterns.  Or "proc case", but again that's just a really
ugly language wart, IMO uglier than just writing out the longhand
version of "proc x -> case x of".

--
Chris Smith

_______________________________________________
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

Mikhail Vorozhtsov
On 07/12/2012 04:27 AM, Iavor Diatchki wrote:

> Hello,
> I am late to the discussion and this is not entirely on topic, for which
> I apologize, but I like the multi-branch case syntax someone mentioned
> earlier:
>
> Writing:
>
>  > case
>  >   | p1 -> e1
>  >   | p2 -> e2
>  >   | ...
>
> desugars to:
>
>  > case () of
>  >   _ | p1 -> e2
>  >     | p2 -> e2
>  >     | ...
>
> -Iavor
> PS:  I think it also makes sense to use "if" instead of "case" for this.
>   Either way,  I find myself writing these kind of cases quite often, so
> having the sugar would be nice.
See [1]. I plan to implement it after lambda-case goes in.

[1] 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
Reply | Threaded
Open this post in threaded view
|

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

Cale Gibbard
In reply to this post by Chris Smith-31
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.

case of { ... }

looks much better to me than

\case of { ... }

and the former makes sense to me as a simple extension of operator
sections to another part of the syntax.

Does anyone else agree?

On 6 July 2012 20:40, Chris Smith <[hidden email]> wrote:

> 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
>
>
> _______________________________________________
> 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: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help

Daniel Trstenjak-2

On Thu, Jul 12, 2012 at 01:38:56PM -0400, Cale Gibbard wrote:
> Personally I don't see why everyone appears to prefer the syntax with
> \ in it over just the obvious case section syntax which was originally
> proposed.

I don't think that the 'case section syntax' is obvious, because I don't
see the similarity between a function definition and a partial function
application.

Always using '\' would be a visual hint for a function definition.


Greetings,
Daniel

_______________________________________________
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

Cale Gibbard
There are of course already lots of ways to create functions which
don't involve \

I mentioned sections (like (+1) desugaring to (\x -> x + 1)) already,
and of course, one can partially apply or compose and transform other
functions without explicit lambdas.

We're not exactly talking about function definitions, so much as
expressions whose value happens to be a function. The point is just
that there are already a few other places in the syntax where the
omission of a value results in a function having the omitted value as
its parameter. At least to me, it seems natural to extend that pattern
in this case.

On 12 July 2012 15:03, Daniel Trstenjak <[hidden email]> wrote:

>
> On Thu, Jul 12, 2012 at 01:38:56PM -0400, Cale Gibbard wrote:
>> Personally I don't see why everyone appears to prefer the syntax with
>> \ in it over just the obvious case section syntax which was originally
>> proposed.
>
> I don't think that the 'case section syntax' is obvious, because I don't
> see the similarity between a function definition and a partial function
> application.
>
> Always using '\' would be a visual hint for a function definition.
>
>
> Greetings,
> Daniel

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

Common syntax for casing/matching (Re[2]: Call to arms: lambda-case is stuck and needs your help)

Bulat Ziganshin-2
In reply to this post by wagnerdm@seas.upenn.edu
Hello wagnerdm,

Thursday, July 5, 2012, 7:22:38 PM, you wrote:

>> After 21 months of occasional arguing the lambda-case proposal(s) is

this reminded me old joke about PL/I: camel is the horse created by committee

i propose to return back and summarize all the requirements we have in
this area. and then try to develop global solution matching them all.
my summary of requirements follows:

> Now we have 3 ways to performing casing/matching:

> function definition:  f (Just x) (Just y) | x>0 = ...  multi-line, multi-parameter
> case statement: case ... of Just x | x>0 -> ... multi-line, single-parameter, different syntax
> lambda: \(Just x) (Just y) -> ...  single-line, multi-parameter, case-like syntax

> What we probably need is to have common syntax for all 3 cases.



another interesting feature may be ruby-style matching defined by
execution of special function `match` instead of pattern matching:

switch var of
  1+1     -> print "var==2"
  [5..10] -> print "var in [5..10]"
  (>20)   -> print "var>20"

where (var `match` (1+1)), (var `match` [5..10]), (var `match` (>20)) is tested


--
Best regards,
 Bulat                            mailto:[hidden email]


_______________________________________________
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: Common syntax for casing/matching (Re[2]: Call to arms: lambda-case is stuck and needs your help)

Twan van Laarhoven
On 2012-07-12 23:48, Bulat Ziganshin wrote:
> another interesting feature may be ruby-style matching defined by
> execution of special function `match` instead of pattern matching:
>
> switch var of
>    1+1     -> print "var==2"
>    [5..10] -> print "var in [5..10]"
>    (>20)   -> print "var>20"
>
> where (var `match` (1+1)), (var `match` [5..10]), (var `match` (>20)) is tested

With view patterns you can write

     case var of
         ((== 1+1)         -> True) -> print "var==2"
         ((`elem` [5..10]) -> True) -> print "var in [5..10]"
         ((> 20)           -> True) -> print "var>20"

Or you can just use guards, of course.


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: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help

John Lask
In reply to this post by Cale Gibbard
On 13/07/2012 3:08 AM, Cale Gibbard wrote:

> Personally I don't see why everyone appears to prefer the syntax with
> \ in it over just the obvious case section syntax which was originally
> proposed.
>
> case of { ... }
>
> looks much better to me than
>
> \case of { ... }
>
> and the former makes sense to me as a simple extension of operator
> sections to another part of the syntax.
>
> Does anyone else agree?
>

yes.
I prefer "case of" rather than "\case of" for aesthetic reasons.

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