[Haskell-cafe] Unnecessarily strict implementations

Jan Christiansen jac at informatik.uni-kiel.de
Thu Sep 2 03:25:59 EDT 2010


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


More information about the Haskell-Cafe mailing list