It seems there is previous background here that I am unaware of. I'll chime in anyway.
What you describe as the "wrong semantics" seems to me to be the more appropriate. I am inferring that your expected behavior is explained such that the first server match ought to fail (and fall through to the second server match) because the pattern in the let fails. This seems odd to me. If the parse test expression yields a Just constructor, then hasn't the first server match succeeded and we ought now commit to the let expression? I apologize if this should be obvious to anyone familiar with the extension. On Dec 4, 2007 2:46 PM, Neil Mitchell <[EMAIL PROTECTED]> wrote: > Hi > > > 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 ..." > > This now has the wrong semantics - before if parse text returned Just > [] the error invalid request branch was invoked, now its a pattern > match failure. > > I haven't used pattern guards that much (but will once Haskell' > standardises them, or they get implemented in Hugs!), but their syntax > seems quite natural. This extension seems to make it harder to > understand them, and gives some nasty , | parsing issues for a human > at least - quite possibly for a compiler too. Perhaps if you gave a > little grammar for extended pattern guards (compared to the original) > it would be easier to see how naturally they fit in. > > Thanks > > Neil > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe