Re: [Haskell] Nested guards?

Neil Mitchell 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 ..."
> 
> 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 missed that, thanks.

The MonadPlus way is not as elegant, but not too ugly I think:

server text =
  do   Just xs <- return $ parse text
       do   guard $ "field1" `elem` xs
            return "... do one thing ..."
         `mplus` do
            guard $ "field2" `elem` xs
            return "... do something else ..."
    `mplus`
       return "... invalid request ..."

Zun.

Re: Re: [Haskell] Nested guards?

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 <ndmitchell <at> gmail.com> 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

Re: Nested guards?

Wolfgang Jeltsch wrote:

> I cannot resist citing Henning Thielemann [...]

Amen to that.

RE: [Haskell] Nested guards?

[redirecting to Haskell Cafe]

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

I think it is helpful to distinguish "superficial" complexity from "deep" complexity.   All of Haskell's
syntactic sugar is just that: it can be translated into a small purely-functional language using
straightforward translation schemes.  Even something relatively complicated like the "order by/group
by" extension that Phil and I proposed at this year's Haskell workshop, has an easy translation that takes
a dozen or two lines to give in full detail.

In contrast, something like higher order functions, or mutable state, is deep complexity. Both have a
pervasive effect on the language semantics and on its implementation.  (The effect of mutable state is
much, much worse, but they are both deep.)


Concerning Haskell, I'm quite relaxed about superficial complexity, as you'll have seen from what
happens in GHC.  Section 3.6 of the History of Haskell paper addresses this point specifically [1].  You may
disagree with the choice made by the Haskell committee at the time, and with subsequent developments, but
it was quite a conscious choice, and one not without its advantages.

Simon

[1] http://research.microsoft.com/%7Esimonpj/papers/history-of-haskell/history.pdf

_______________________________________________

RE: Nested guards?

| 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