Folks
Once the ICFP dust is subsided I want to get back to
completing the Haskell 98 bug list, and then producing
a version of the report that includes all the fixes.
Re take and drop
> | * Opinion seems pretty evenly balanced between
> | (A) Accept negative arg (take yields [], drop yields xs)
> | (B) Fail on negative arg
I've decided on (A).
Three new things have come up:
1. Marcin Kowalczyk pointed out that scanl1 and
scanr1 fail on empty args, whereas they could perfectly well
return [] on such arguments. I asked the World Scan Expert, John
O'Donnell about this. He agrees.
| [This] makes them more consistent with the Haskell98 definitions of
| scanl and scanr, and I can't think of any situation where it would
| actually be better to produce the error message if the list argument
| is empty.
|
| However, I continue to think that the definitions of scanl and scanr are
| badly broken in Haskell, and I always have to use my own definitions
| in all my work where scans are used. I'm not proposing fixing the
| definitions of scanl and foldl, because this is far more than a typo.
So I propose to adopt this change, in the same spirit as that for take/drop.
2. George Russell pointed out that floor(Inf) and floor(NaN) are not
defined in Standard Haskell; indeed GHC and Hugs have different behaviour.
Alternatives
(A) Make it explicit that the behaviour in these circumstances
is undefined, so that impls may differ
(B) Specify that floor should fail (i.e. give rise to a call to
error)
(would this have an performance penalty?)
This is what SML does
I'm inclined to do (A) because it binds impls less, and because it is
in effect what the report currently says. But I might yield to
a determined attack in favour of (B).
3. Manuel points out
| There is a typo in the grammar for list comprehensions in
| Section 3.11 of the Haskell report. It says,
|
| exp -> [ exp | qual_1, ..., qual_n ] (list comprehension, n >= 0)
|
| but I think, it should read `n >= 1'. At least, it says `n
| >= 1' five lines later and both GHC and Hugs raise an error
| when fed the expression `[1 |]'.
|
| Furthermore, I am unsure about the intention of the
|
| qual -> (empty qualifier)
|
| production, which would make `[1 | , ]' legal, or also `[1 |
| True, ]' - both of which GHC and Hugs don't like.
I must say that I'm strongly tempted to disallow empty qualifiers
and make n>=1. I'm not sure how this change crept in in the first
place. Does anyone care? Urgle.
Simon
