A couple of minor counter-quibbles:-
Pablo E. Martinez Lopez suggests:
> You can define your own "sequential if" a la Hoare:
>
>data GuardedExp a = Bool :? a
>
>seqif :: [GuardedExp a] -> a
>seqif [True:?a] = a
>seqif ((b:?a):x:xs) = if b then a else seqif (x:xs
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
I can see the arguments for the pattern guard extension and the syntax
seem reasonable.
I also agree with Chris on the shortcomings of if-then-else. (I have
disliked it in any language where I've seen it, and it "feels"
un-Haskell-like to me.) On the other hand, the suggested
case
| ..
>I have longstanding dislike of Haskell's expression conditional:
> The problem comes when several conditions are
> present, provoking a rightward march. In this case I use
>
> if test1 then
> part1
> else if test2 then
>
Tommy Thorn writes:
> My only worry is that Haskell (if not already) is turning into the C++
> of functional languages, ie. feature upon feature. Haskell is already
> quite a mouthfull to learn.
This worries me too. Not least is the problem that <- is not a
particularly natural syntax for 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
In `A new view of guards', Simon cited
> [2] W Burton, E Meijer, P Sansom, S Thompson, P Wadler, "A (sic) extension
> to Haskell 1.3 for views", sent to the Haskell mailing list
> 23 Oct 1996
Was that posted on this Haskell mailing list? Does anyone know where I could
get a copy
Thanks for feedback about pattern guards. Here are some quick responses.
1. Several people have suggested something along the lines of being
able to backtrack half way through a pattern guard. I considered this
but (a) I couldn't see a nice syntax for it and
(b) it's against the spirit of
18 matches
Mail list logo
