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

[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. Changing an argument from non-strict to strict could have very
severe consequences, e.g. non-terminaton, throwing exceptions where no
exceptions would be thrown in the original definition, etc.  For (++), the
Prelude says that it is strict in its first argument, but non-strict in its
second:
https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#verbatim-243

Very similar functions in this respect are (&&) and (||), and I guess
people would be a bit upset if they suddenly forced evaluation of their
second argument... :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180305/9aa5f5a7/attachment.html>