foldl' semantic change

[Bart Massey]

I guess by "packages may have come to rely on it" you mean some situation
where performance is improved by the implicit strictness? It's hard for me
to imagine relying on getting bottom instead of a result. However, it's
also hard for me to imagine relying on foldl' forcing the initial value in
the case of folding on an empty list, and in non-empty list cases the
folding function is likely going to be strict on the accumulator anyhow.
(The last example I gave is an exception to that rule.)

As to the lack of documentation of laziness, my understanding is that
functions in Data.List are expected to be lazy anywhere that their
strictness is not explicitly documented? I don't know if there's actually
language like that in any of the Reports, but the Haddock for Data.List
says, among other things:

> For a general Foldable
<https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Foldable.html#t:Foldable>
 structure this should be semantically identical to,

foldl f z = foldl'
<https://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-OldList.html#v:foldl-39->
f z . toList <https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Foldable.html#v:toList>

which doesn't seem to be actually the case right now, but does seem to be
desirable. (Is the prime on the wrong side here? This seems backward to me,
but I'm easily confused.)

Anyhow, I'll be disappointed if it remains no longer viable to write  last
= foldl' (flip const) undefined  as I did above. It makes the language
harder to teach, and is nonintuitive to me.

On Fri, Jun 10, 2016 at 9:35 AM David Feuer <david.feuer at gmail.com> wrote:

> I would certainly have agreed back when 4.8 was in development. This was
> undoubtedly a breaking change. The fact that it's now been out for some
> time muddies the waters. So does the fact that the strictness has never
> been documented. It seems likely that most packages relying on the old
> behavior have been updated, and it's possible that some may have come to
> rely on it. I see this unfortunate situation as something of an opportunity
> to take a fresh look and decide what we want.
>
> On the pro-revert side,
>
> foldl'new f b xs = b `seq` foldl'old f b xs
>
> which seems considerably less challenging than implementing the lazy
> version from scratch with the built-in GHC magic. But there could be times
> when that leads to some efficiency problem.
> On Jun 10, 2016 12:10 PM, "Bart Massey" <bart.massey at gmail.com> wrote:
>
>> -1 on retaining this. Part of the implied contract of Data.List is that
>> all functions be as lazy as possible. Besides, a change that potentially
>> breaks old programs that use foldl' seems like a bad idea unless there's a
>> really strong reason for it. I don't have an existing example offhand, but
>> it seems at least possible that something like
>>
>>     last = foldl' (flip const) undefined
>>
>> is out there...
>>
>> On Fri, Jun 10, 2016 at 5:29 AM David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> The semantics of foldl' for lists were changed between base 4.7 and base
>>> 4.8. Specifically, foldl' became strict in the initial value of its
>>> accumulator. I opened http://ghc.haskell.org/trac/ghc/ticket/12173 to
>>> report this. The change was entirely accidental, according to Joachim
>>> Breitner. However, Duncan Coutts indicated he is pleased with the change. I
>>> don't personally have a dog in this race, but I feel very strongly about
>>> three things:
>>>
>>> 1. The strictness should be fully documented, both in Haddock and the
>>> next Haskell Report (the Haskell 2010 Report does not go into sufficient
>>> detail to support either choice).
>>>
>>> 2. There should be *one* meaning of foldl' in base. Thus the default
>>> Foldable instance should match the ones for lists and arrays.
>>>
>>> 3. The containers package should be consistent with base in this regard.
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160610/8618bd48/attachment.html>