Hi, On 02.09.2010, at 01:35, Daniel Fischer wrote:
It's not that it's not as non-strict as possible per se. (Sorry, had to :) It's that intersperse's current definition (in GHC at least) can cause a space leak. In this case, making the function less strict can cure it, in other cases, more strictness might be the solution.
I would be very happy if you would share this example with me. I am looking for an example where the current implementation of intersperse or inits causes a space leak for quite a while now.
On the other hand, we currently have
intersect [] _|_ = []
and one of intersect _|_ [] and intersect [] _|_ must give _|_. Which one is a matter of choice.
I am sorry for not being precise. You are right. But right now we have intersect xs [] = _|_ for every list xs terminated by _|_. But I suffices to evaluate xs to head normal to decide that the result should be []. That is, we could have intersect [] _|_ = [] and intersect (_|_:_|_) [] = [] or intersect [] (_|_:_|_) = [] and intersect _|_ [] = [] and the current implementation satisfies neither.
And before that, the rule intersect [] _ = [] if the current behaviour of intersect [] should be retained.
That's a deal.
The implication (<=) :: Bool -> Bool -> Bool is too strict as well. We have False <= _|_ = _|_ as well as _|_ <= True = _|_ while one of these cases could yield True.
I'm not convinced either should (nor that they shouldn't).
I think this is a matter of elegance rather than a matter of efficiency. In the same way as I prefer False && _|_ = False over False && _|_ = _|_ I prefer False <= _|_ = True over False <= _|_ = _|_
The last slide lists among the problems "proposes undesirably inefficient functions (reverse)". I wouldn't equate 'not minimally strict' with 'too strict'. Minimal strictness also can have negative effects, one must look at each case individually.
I second this but in my opinion the minimally strict implementation should be the default if there is no reason against it. Cheers, Jan