Thoughts about currying and optimisations
Hello Café, An idea came to me: unless the compiler notices that stuffA and stuffB are equivalent, would it be correct to suppose that A is better than B? stuffA x = if someComputationallyExpensiveTest x then doSomething else doSomethingElse stuffB x y = if someComputationallyExpensiveTest x then doSomething y else doSomethingElse y I explain: in stuffA, the function only depends on x, so when doing: a = stuffA xxx runs the expensive test once and for all, and a can directly be bound to doSomething or doSomethingElse so calling after: a foo a bar won't run the test Whereas: b = stuffB xxx is valid due to curryfication, but: b foo b bar will both run the expensive test
I believe this transformation is called the 'full laziness' optimization. It can introduce space leaks if the computationally expensive test is replaced with a reference to a space expensive value. Edward Excerpts from Yves Parès's message of Tue May 31 15:14:07 -0400 2011:
Hello Café, An idea came to me: unless the compiler notices that stuffA and stuffB are equivalent, would it be correct to suppose that A is better than B?
stuffA x = if someComputationallyExpensiveTest x then doSomething else doSomethingElse
stuffB x y = if someComputationallyExpensiveTest x then doSomething y else doSomethingElse y
I explain: in stuffA, the function only depends on x, so when doing: a = stuffA xxx runs the expensive test once and for all, and a can directly be bound to doSomething or doSomethingElse so calling after: a foo a bar won't run the test
Whereas: b = stuffB xxx is valid due to curryfication, but: b foo b bar will both run the expensive test
It can introduce space leaks if the computationally expensive test is replaced with a reference to a space expensive value.
You mean if the rest of stuffX's body keeps a reference to that value, I
suppose? (I suppose, or else that value would be useless).
Ok, so GHC does detect that case and optimizes it.
2011/5/31 Edward Z. Yang
I believe this transformation is called the 'full laziness' optimization. It can introduce space leaks if the computationally expensive test is replaced with a reference to a space expensive value.
Edward
Excerpts from Yves Parès's message of Tue May 31 15:14:07 -0400 2011:
Hello Café, An idea came to me: unless the compiler notices that stuffA and stuffB are equivalent, would it be correct to suppose that A is better than B?
stuffA x = if someComputationallyExpensiveTest x then doSomething else doSomethingElse
stuffB x y = if someComputationallyExpensiveTest x then doSomething y else doSomethingElse y
I explain: in stuffA, the function only depends on x, so when doing: a = stuffA xxx runs the expensive test once and for all, and a can directly be bound to doSomething or doSomethingElse so calling after: a foo a bar won't run the test
Whereas: b = stuffB xxx is valid due to curryfication, but: b foo b bar will both run the expensive test
participants (2)
-
Edward Z. Yang -
Yves Parès