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
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't
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
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
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 ...;
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
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
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
"let p = e"
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 replace
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
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.
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,
| 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'
|
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
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
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
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 down.
17 matches
Mail list logo
