Hello everyone, Just to clarify, the intended semantics of my example was that it should behave as if we were to duplicate the common prefix: server text | Just xs <- parse text, "field1" `elem` xs = ... do one thing ... | Just xs <- parse text, "field2" `elem` xs = ... do something else ... server _ = ... invalid request ... The difference is that the nested version is shorter, and probably way easier for the compiler to produce reasonable code. As I said in my first post, I am not sure what would be a nice notation for nesting the guards: the notation that I used in the example was just the first thing that came to mind, we might be able to do better. -Iavor On Dec 4, 2007 7:26 PM, Nicolas Frisby wrote:

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