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

73 messages
1234
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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 expressionp -> 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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.patchThe 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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 >     | ...-IavorPS:  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 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

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

 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