<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2018-03-04 10:42 GMT+01:00 Clinton Mead <span dir="ltr"><<a href="mailto:clintonmead@gmail.com" target="_blank">clintonmead@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Adding that case will require one to evaluate the second argument to check it's empty before allowing one to examine the result.<div><br></div><div>Consider `x ++ some_list_that_takes_a_long_<wbr>time_to_produce_its_first_<wbr>element`.</div></div></blockquote><div><br></div><div>In the extreme, evaluating the 2nd argument might not even terminate or it could throw an exception.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>In this case your proposal will not be an optimisation. </div></div></blockquote><div><br></div><div>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: <a href="https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#verbatim-243">https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#verbatim-243</a></div><div><br></div><div>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... :-)</div></div></div></div>