This is definitely a bug in the syntax of Haskell. I don't see any
simple fix to the grammar except to change var to qvar in pat and
apat. This probably isn't a good idea since it would allow local
variables whihc shadow qualified imports or some such. We could add a
line saying `qualifiers
Dear all,
I stumbled across a subtle discrepancy between Hugs and GHC. After some
thought I decided that the Glasgow Haskell Compiler is `buggy'.
However, since the Report is not explicit about this issue (at least I
did not find a clue) the case is probably not settled. Assume we have
the
| Hugs is perfectly happy with this. ghc, however, complains that `empty'
| ist not in scope, which is in accordance with the rule (p. 58) saying
| that `the names brought into scope must be prefixed by the name of the
| imported module'. Hence I am forced to write:
Good point! The report is
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
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
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
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
|
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"
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
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
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
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
16 matches
Mail list logo
