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... :-)

On 03/05/2018 07:13 AM, Ben Franksen wrote:

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?

Rewrite rules apply at compile time and don't force any computation. The second rule fires only if the second argument of (++) is syntactically []. Otherwise the code doesn't change, and strictness is preserved. Cheers, Li-yao

Generated code, sometimes including "deriving"-generated code. On Mon, Mar 5, 2018 at 5:18 PM, Ben Franksen wrote:

Am 05.03.2018 um 13:40 schrieb Li-yao Xia:

...

On 03/05/2018 07:13 AM, Ben Franksen wrote:

...

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?

Rewrite rules apply at compile time and don't force any computation. The second rule fires only if the second argument of (++) is syntactically []. Otherwise the code doesn't change, and strictness is preserved.

Thanks, yet another thing learned. So

let ys = [] in xs ++ ys

will traverse the spine of xs but

xs ++ []

will not. Interesting.

(But who writes something like "xs ++ []" in a real program?)

Cheers Ben

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On 6 March 2018 9:25:43 am AEDT, Andrew Martin wrote:

Actually, it is likely that neither of the examples you gave will end up traversing the spine of the list. The definition of ys would almost certainly be inlined, and then the rule would fire.

Sent from my iPhone

...

On Mar 5, 2018, at 5:18 PM, Ben Franksen wrote:

...

...

On 03/05/2018 07:13 AM, Ben Franksen wrote: 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

Am 05.03.2018 um 13:40 schrieb Li-yao Xia: true

...

because (++) really is non-strict, I tested that, with -O2. How do you explain that?

Rewrite rules apply at compile time and don't force any computation. The second rule fires only if the second argument of (++) is syntactically []. Otherwise the code doesn't change, and strictness is preserved.

Thanks, yet another thing learned. So

let ys = [] in xs ++ ys

will traverse the spine of xs but

xs ++ []

will not. Interesting.

(But who writes something like "xs ++ []" in a real program?)

Cheers Ben

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

For determining whether xs is traversed, it doesn't really matter whether or not the rule fires and replaces zs = xs ++ ys with just zs = xs. In either case if you traverse the spine of zs to a given depth, it'll force the spine of xs to the same depth. Just having xs ++ ys in the code doesn't traverse the spine of xs, and even evaluating it to WHNF only evaluates xs to the same degree as evaluating xs to WHNF directly. The question is whether it's allocating a new list spine as it goes on top of evaluating the spine of xs, but there shouldn't be any impact on what is evaluated when.