Nested guards?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Nested guards?

Iavor Diatchki
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: Nested guards?

Roberto Zunino-2
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.
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: Nested guards?

Taral
On 12/4/07, Roberto Zunino <[hidden email]> 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 <[hidden email]>
"Please let me know if there's any further trouble I can give you."
    -- Unknown
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: Nested guards?

Per Gundberg
In reply to this post by Iavor Diatchki
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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell
>


_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: Nested guards?

Christian Maeder-2
In reply to this post by Iavor Diatchki
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
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

RE: Nested guards?

Simon Peyton Jones
In reply to this post by Iavor Diatchki
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: [hidden email] [mailto:[hidden email]] 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
| [hidden email]
| http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: Nested guards?

Wolfgang Jeltsch-2
In reply to this post by Per Gundberg
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
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: Nested guards?

Johannes Waldmann
Wolfgang Jeltsch wrote:

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

Amen to that.
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: Nested guards?

Roel van Dijk-3
In reply to this post by Simon Peyton Jones
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.
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

RE: Nested guards?

Simon Peyton Jones
| 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
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: Nested guards?

Bas van Dijk-2
On Dec 6, 2007 9:06 AM, Simon Peyton-Jones <[hidden email]> 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
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell