[Haskell-cafe] missing optimization for (++)

[Ben Franksen]

Am 05.03.2018 um 09:02 schrieb Sven Panne:
> 2018-03-04 10:42 GMT+01:00 Clinton Mead <clintonmead at gmail.com>:
> 
>> Adding that case will require one to evaluate the second argument to check
>> it's empty before allowing one to examine the result.
>>
>> Consider `x ++ some_list_that_takes_a_long_time_to_produce_its_first_
>> element`.
>>
> 
> In the extreme, evaluating the 2nd argument might not even terminate or it
> could throw an exception.
> 
> 
>> In this case your proposal will not be an optimisation.
>>
> 
> I would go even a step further: The proposed additional case would not just
> be worse for some cases, it would be completely wrong: The Prelude part of
> the Haskell Report specifies among other things the strictness of function
> arguments. [...]

Okay, okay, I got it. I did not think about strictness when I asked. The
funny thing is that the two fusion rules combined, as explained by
Josef, seem to cause this shortcut to be taken. But that can't be true
because (++) really is non-strict, I tested that, with -O2. How do you
explain that?

Cheers
Ben