Just wanted to add two minor points to the discussion. Beforehand let
me say that I *really* like Simon's proposal [despite the various
objections]. Mainly, because it's a small upwards compatible change with
a considerable gain.
Going back to Simon's first `clunky' example.
> Now consider the f
I've marked the most interesting part of this mail with "#" signs below.
Alex Ferguson writes:
> Let me rephrase then; it wasn't a convincing example, because the
> non-pattern-guarding version (5a vs. 5) was actually simpler and
> cleaner, but in basically the same style.
Meanwhile it has b
Heribert Schuetz:
> I wanted to point out
> that no use of patterns is really "essential" (see also the equivalences
> below), or at least that it is a bit arbitrary what one considers
> essential.
Let me rephrase then; it wasn't a convincing example, because the
non-pattern-guarding version (5a
Alex Ferguson writes:
> Heribert Schuetz:
>
> > 3. From Alex' example (version 5a) one could have learned that we do not
> >need guards at all, [...]
>
> I don't know if Heribert suggests this in earnest, or as a reductio
> ad absurdum of my suggestion, [...]
Closer to the latter, but only
I think Heribert Schuetz makes a good argument that Simon's
proposed notation would work better if adapted to the Maybe monad.
Simon's original proposal struck me as something of a hack,
whereas Schuetz's variant seems more disciplined. -- P
Heribert Schuetz:
> 3. From Alex' example (version 5a) one could have learned that we do not
>need guards at all, because all sorts of guards (today's Haskell
>guards, Peyton-Jones-style guards, and nested guards) can be replaced
>by the Maybe monad in a *straightforward* way:
I don
Here are some more thoughts about qualifier lists as guards (this time
starting with the less important ones).
Heribert.
1. I agree that my "simplify" example was not so good. In fact, one
could do without nested qualifiers/guards easily because the first
two qualifiers
"s <- Just
At 09:15 97-04-28, Simon L Peyton Jones wrote:
>A proposal
>~~~
>The proposal I want to make is simple:
>
>Instead of being a boolean expression,
>a guard is a list of qualifiers,
>exactly as in a list comprehension.
>
>That is, the only syntax change is to
Oh, I forgot to say, concerning the Alternative Syntax (strict where's)
Simon mentions; I think this is not supportable, particularly for the
program-breaking reason SPJ mentions. (And especially because lots of
the borken programs would be mine, and I shudder at the thought of
adding ~'s all ov
> Is this a storm in a teacup? Much huff and puff for a seldom-occurring
> situation? No! It happens to me ALL THE TIME. The Glasgow Haskell Compiler
> is absolutely littered with definitions like clunky.
I experience the same problem all the time as well and it drives me crazy.
I think this
Tony Davie writes:
> >I'm quite comfortable with the idea. Guards are part of the lhs of an
> >equation, and that is where binding takes place.
> >
> >The <- syntax worries me a bit, because in the comprehension use it has a
> >different type, but the let syntax is available, and one can write
> >
Brian Boutel writes:
> The <- syntax worries me a bit, because in the comprehension use it has a
> different type, but the let syntax is available, and one can write "let p =
> e" "for p <- e". I think that, to reduce possible confusion, I would use,
> and teach, the let form. Given that, I don't
Greg said:
>To parade my ignorance... Something that's always puzzled me about Haskell
>is when to do something on the left and when on the right of a function
>definition. For example, there must be at least 4 ways of writing the factorial
>function: pattern match; guard; if ... then ... else ..
I'm quite comfortable with the idea. Guards are part of the lhs of an
equation, and that is where binding takes place.
The <- syntax worries me a bit, because in the comprehension use it has a
different type, but the let syntax is available, and one can write
"let p = e" "for p <- e". I think
John Lauchbury writes:
> Simon's syntax also provides a viable alternative to @ patterns
> f x @ (Just 3) y = e
> f x y | Just 3 <- x = e
> though it is slightly less convenient in certain contrived examples (but
> very much less ad hoc).
Reversing this idea, we have another syntax for S
I very much like Simon's proposal.
It's useful, clean, fits neatly into the syntax,
and does not cause any difficult implementation problems.
In other words, it fits all the requirements of good language design.
Tony Davie wrote:
> Yes. I really like the fact that at last guards in comprehension
To parade my ignorance... Something that's always puzzled me about Haskell
is when to do something on the left and when on the right of a function
definition. For example, there must be at least 4 ways of writing the factorial
function: pattern match; guard; if ... then ... else ...; list comprehe
DISCLAIMER: I've never written a `large' application in Haskell and
perhaps don't appreciate the problems. I _do_ use Haskell for personal
progams
because its so much quicker and easier to get right. (Work is mandated in
C++)
I like Simon Peyton Jones basic extension of guards. However, I'm a bit
>I'm quite comfortable with the idea. Guards are part of the lhs of an
>equation, and that is where binding takes place.
>
>The <- syntax worries me a bit, because in the comprehension use it has a
>different type, but the let syntax is available, and one can write
>"let p = e" "for p <- e". I th
Simon (PJ) sez:
> Is this a storm in a teacup? Much huff and puff for a seldom-occurring
> situation? No! It happens to me ALL THE TIME.
I have to join Simon out of the closet, and confess that I write
Clunky Functions rather a lot too, or at least find myself going to
significant lengths to a
I found Simon Peyton Jones' proposal for guarded equations very
interesting and convincing. However, I see situations where yet more
flexibility in guarded expressions would be useful, and I have included
a suggestion for an extension below. I hope the following is
understandable and makes sense,
I love Simon's suggestion. It gives me all the right vibes. And <- seems to
me to be the right connective to use.
At the risk of beating my hobby horse, let's not think of <- solely in
terms of monads. It is certainly appropriate there, but it is also
appropriate for lists when thought of purely
| We can avoid both the case expressions and the helper function by Simon
| Peyton Jones' guard syntax
|
| -- version 3
| simplify (Plus e e') | s <- simplify e ,
|s' <- simplify e',
|(Val 0) <- s
| = s'
|
simonpj's proposal on guards:
> > I would really welcome feedback on this proposal. Have you encountered
> > situations in which pattern guards would be useful? Can you think of ways
> > in which they might be harmful, or in which their semantics is non-obvious?
> > Are there ways in which the
> I would really welcome feedback on this proposal. Have you encountered
> situations in which pattern guards would be useful? Can you think of ways
> in which they might be harmful, or in which their semantics is non-obvious?
> Are there ways in which the proposal could be improved? And so on.
> Is this a storm in a teacup? Much huff and puff for a seldom-occurring
> situation? No! It happens to me ALL THE TIME. The Glasgow Haskell Compiler
> is absolutely littered with definitions like clunky.
I agree! I considered a similar extension some years ago now,
but I never wrote it dow
A new view of guards
Simon Peyton Jones, April 1997
This note proposes an extension to the guards that form part of function
definitions in Haskell. The increased expressive power is known (by me
anyway!) to be useful. The
27 matches
Mail list logo
