I agree with it being complicated. I don't know of any compiler
that implements it correctly. Do you say your combinators do?
That said, I don't think it can be replaced easily without breaking
existing code, so I'm unwilling to change unless someone can show
an alternative that handles 99.9% of the existing code.
-- Lennart
Doaitse Swierstra wrote:
It is with some hesitation that I want to bring up another point, in
which Haskell' could be an improvement above Haskell: the offside rule.
Although I manage to live with it, I encountered many problems with it
in the past:
1) it is impossible to explain the precise workings of the rule to a
class of first years undergraduates
This is extremely demotivating. I do not want to teach using the
following utterances: "If you write your programs in the same style as I
do on my slides, you will usually get away with it". Students are
perfectly happy to accept that complicated things are complicated, but
are not very willing to buy complicated explanations for things which
ought to be simple. I furthermore think it is waist of time to to have
to go into this in my lectures. I do not think the alternative, in which
you always have to write { ; ; } is an option. A language in which every
let is followed by a { is plain stupid; just like in Pascal, where each
procedure, function, const, var and begin keyword has to be preceded by
a (thus superfluous) semicolon.
2) it has created havoc among students for years, with Hugs
complaining about improper semicolons, whereas
the student has not typed a single semicolon in his program. many
students think Haskell is a complicated language,
mainly because of offside rules, (and the monomorphism restriction
of course)
3) it is formulated in an implementation oriented way, prohibiting
proper tool support for parser generation
With our parser combinator library we have created very efficient
error-correcting parsers (far more efficient that Parsec based ones) for
quite a few languages (including Haskell). Creating one for Haskell
however became a nightmare, although we have managed to encapsulate the
problem in a special offside parser combinator. Our parsers perform
error-correction automatically, and this is simply not compatible with a
prescription in the language definition as to how certain parse errors
should be dealt with (especially that they are not errors). We had to
put parser-brain-surgery into place in order to cope with the
description of the offside rule. Although the problem is solved by the
introduction of the offside combinator now, I think it is a sign of
unhealthiness of the formulation, which is too implementation dependent.
4) based on many examples my claim is that almost no Haskell
programmer can always correctly apply to offside rule
We might go back to something simpler, like e.g. the Miranda(tm) rule,
in which declarations have to start in the same column, and a
declaration extends to the lower right of its first character.
Doaitse Swierstra
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
