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
1. Marcin Kowalczyk pointed out that scanl1 and
scanr1 fail on empty args, whereas they could perfectly well
return [] on such arguments.
Does the same apply for foldl1 and foldr1?
Regards,
Malcolm
On 15-Mar-2000, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
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
On 15-Mar-2000, Malcolm Wallace [EMAIL PROTECTED] wrote:
1. Marcin Kowalczyk pointed out that scanl1 and
scanr1 fail on empty args, whereas they could perfectly well
return [] on such arguments.
Does the same apply for foldl1 and foldr1?
No, returning [] from foldl1 and foldr1 would
Fergus Henderson wrote:
[snip]
For FLOOR_{F-I}(NaN), the result is defined as a NaN:
[snip]
But in both cases this doesn't really make much sense to me,
since here the result type of the operation is an integer rather
than floating point type. I guess the earlier part of 6.1 does
shed a
3. Manuel points out
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.
The report is in a bit of a mess here.
The top of section 3 (the summary of exp syntax) also has n=1.
| * Opinion seems pretty evenly balanced between
| (A) Accept negative arg (take yields [], drop yields xs)
| (B) Fail on negative arg
I've counted up votes. I was right about it being
evenly balanced. I count 9 people in favour of (A) and 9 in
favour of (B), not counting me.
If
Simon PJ wrote:
| I've counted up votes. I was right about it being
| evenly balanced. I count 9 people in favour of (A)
| and 9 in favour of (B), not counting me.
I haven't said anything so far, but I must speak up
now.
Counting votes by reading the e-mails sent to the mailing
list is
| I like symmetry arguments---but as a compiler writer I also
| have another reason to vote for take and drop to work on negative
arguments. It
| allows me to write foldr definitions (which I can deforest,
| reason about equationally, etc.) without having to scribble down a side
condition!
Hello,
I'm worrying that there are too many constraints put on the definition
of a function's domain. Thus, if you agreed on the domains of take, drop,
etc. and their semantics, please give a definition, say D, of these functions
in terms of the ordinary list constructors. I would consider any
As an implementor of eager haskell, I sometimes think it would be nice
if all list functions checked the length of their argument, thus
stamping out infinite lists forever!
In al seriousness, the prelude functions should support a lazy
programming style as far as is possible. I found the "split
Folks
The recent discussion has highlighted three things that I
propose to treat as 'Haskell 98 typos'. Even if you have
not been reading the dicussion, please read this, since
I have my H98 editor's hat on, and I propose some minor
changes to the published H98.
Simon
Partition
~
On Tuesday, January 25, 2000 10:00 AM, Joe English [SMTP:[EMAIL PROTECTED]] wrote:
Is the filter/filter definition semantically equivalent to:
partition p xs = foldr select ([],[]) xs
where
select x ~(ts,fs) | p x = (x:ts,fs)
| otherwise = (ts, x:fs)
13 matches
Mail list logo
