2018-03-04 10:42 GMT+01:00 Clinton Mead
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-24... 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... :-)