Hi, Lately I have been using pattern guards more than usual and I find that occasionally I need to nest them (i.e., I have alternatives with a common prefix). This seems to happen when I need to do some preliminary checking, followed by some decision making. Here is an example: server text | Just xs <- parse text , | "field1" `elem` xs = ... do one thing ... | "field2" `elem` xs = ... do something else ... server _ = ... invalid request ... As far as I can see this should be a fairly simple change to the pattern bindings extension. Would anyone else find this a useful feature, and if so what syntax should we use? -Iavor
Iavor Diatchki wrote:
server text | Just xs <- parse text , | "field1" `elem` xs = ... do one thing ... | "field2" `elem` xs = ... do something else ...
server _ = ... invalid request ...
What about: server text | Just xs <- parse text = let x | "field1" `elem` xs = error "... do one thing ..." | "field2" `elem` xs = error "... do something else ..." in x server _ = error "... invalid request ..." Regards, Zun.
On 12/4/07, Roberto Zunino <zunino@di.unipi.it> wrote:
server text | Just xs <- parse text = let x | "field1" `elem` xs = error "... do one thing ..." | "field2" `elem` xs = error "... do something else ..." in x server _ = error "... invalid request ..."
Not the same fallthrough properties. You'd have to clone the "server _" clause into the x clause. -- Taral <taralx@gmail.com> "Please let me know if there's any further trouble I can give you." -- Unknown
Have you looked at the proposed view patterns? It seems like it would cover the case you gave here. I don't know if there's work being done in this area though. http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns //Gundberg
Hi, Lately I have been using pattern guards more than usual and I find that occasionally I need to nest them (i.e., I have alternatives with a common prefix). This seems to happen when I need to do some preliminary checking, followed by some decision making. Here is an example:
server text | Just xs <- parse text , | "field1" `elem` xs = ... do one thing ... | "field2" `elem` xs = ... do something else ...
server _ = ... invalid request ...
As far as I can see this should be a fairly simple change to the pattern bindings extension. Would anyone else find this a useful feature, and if so what syntax should we use?
-Iavor _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Am Mittwoch, 5. Dezember 2007 00:16 schrieb Per Gundberg:
Have you looked at the proposed view patterns? It seems like it would cover the case you gave here. I don't know if there's work being done in this area though.
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
//Gundberg
I cannot resist citing Henning Thielemann (actually translating from German). The following text is from is very good squib about how to become a scripting language hater within five days [1]. Please take it with a grain of humor. I don’t want to offend anyone. Here’s the text:
The root idea of functional programming simplifies many things. No need to distinguish between constants and variables, no “call by reference”, no assignments, no predefined loop structures—everything is manageable and the effects of functions are controllable.
It is clear that this situation must not stay this way. Bit by bit, disciples of Perl and Python discover Haskell and demand that Haskell will be plastered with syntactic sugar until the simplicity of the functional approach isn’t visible anymore. Sadly, they seem to be successful with this as syntax extensions like parallel list comprehensions show.
Many Haskell newcomers don’t seem to bother studying the concept of functions and the wide variety of applications of higher order functions. They rather avoid everything systematic and construct their programs mainly from syntactic sugar like list comprehensions, guards, pattern guards, infix operators and do notation, optionally also with pettifogging recursions. Because they don’t know anything else, they aren’t tired of emphasizing how important such syntactic sugar is. In addition, the strict order of dataflow imposed by functions is attacked again and again. Yes, global variables are just immortal.
[1] <http://users.informatik.uni-halle.de/~thielema/ScriptingHater.html> Best wishes, Wolfgang
Iavor Diatchki wrote:
Hi, Lately I have been using pattern guards more than usual and I find that occasionally I need to nest them (i.e., I have alternatives with a common prefix). This seems to happen when I need to do some preliminary checking, followed by some decision making. Here is an example:
server text | Just xs <- parse text , | "field1" `elem` xs = ... do one thing ... | "field2" `elem` xs = ... do something else ...
server _ = ... invalid request ...
Not having used pattern guards so far, can't you write? server text = case parse text of Just xs | "field1" `elem` xs -> ... do one thing ... | "field2" `elem` xs -> ... do something else ... _ -> ... invalid request ... Christian
Indeed this makes sense. See Section 3 of http://research.microsoft.com/~simonpj/Papers/pat.htm It's really the syntactic/notational problem that has put me off every doing something like this. I just couldn't come up with a compelling syntax. (The syntax GHC uses has the great merit that it's identical to that for list comprehensions.) Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Iavor Diatchki | Sent: 04 December 2007 19:42 | To: Haskell users | Subject: [Haskell] Nested guards? | | Hi, | Lately I have been using pattern guards more than usual and I find | that occasionally I need to nest them (i.e., I have alternatives with | a common prefix). This seems to happen when I need to do some | preliminary checking, followed by some decision making. Here is an | example: | | server text | | Just xs <- parse text | , | "field1" `elem` xs = ... do one thing ... | | "field2" `elem` xs = ... do something else ... | | server _ = ... invalid request ... | | As far as I can see this should be a fairly simple change to the | pattern bindings extension. Would anyone else find this a useful | feature, and if so what syntax should we use? | | -Iavor | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell
Note that Clean also supports nested guards. See section 3.3 of the Clean language report: http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf Unfortunately the html version of the report appears to be broken. The report gives an example of nested guards and explains the semantics with "if then else" expressions.
| Note that Clean also supports nested guards. See section 3.3 of the | Clean language report: | | http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf Interesting, I didn't know that. But (a) Clean guards don't bind, and pattern guards that bind was where this thread started. And (b) the Clean manual says: "To ensure that at least one of the alternatives of a nested guard will be successful, a nested guarded alternative must always have a 'default case' as last alternative". That's a pity. The main point about guards is that failure means "go on to the next equation", a semantics that they could have chosen I guess. Simon
On Dec 6, 2007 9:06 AM, Simon Peyton-Jones <simonpj@microsoft.com> wrote:
b) the Clean manual says: "To ensure that at least one of the alternatives of a nested guard will be successful, a nested guarded alternative > must always have a 'default case' as last alternative". That's a pity. The main point about guards is that failure means "go on to the next equation", a semantics that they could have chosen I guess.
I brought this up some time ago on haskell-prime ( http://thread.gmane.org/gmane.comp.lang.haskell.prime/1561 ). One of the Clean guys mentioned that "the compiler can handle nested-guards with fall-throughs just fine" and that "The reason that a nested guard must have a default case is syntactical, otherwise there could be the dangling-else ambiguity". Bas
participants (10)
-
Bas van Dijk -
Christian Maeder -
Iavor Diatchki -
Johannes Waldmann -
Per Gundberg -
Roberto Zunino -
Roel van Dijk -
Simon Peyton-Jones -
Taral -
Wolfgang Jeltsch