Masklinn writes:
On 2014-03-05, at 22:51 , Greg Ewing
wrote: Masklinn wrote:
On 2014-03-04, at 23:31 , Greg Ewing
wrote:
That comes at the expense of making *everything* a thunk until its value is needed [in Haskell].
Of course not, Haskell allows explicitly forcing a thunk and the compiler/runtime pair can use strictness analysis and not create thunks in the first place.
That doesn't seem fair to me. "Explicitly forcing" by definition means the programmer has decided the value is needed, and "strictness analysis" is an optimization, not part of the language definition. Am I missing something?
Consider that a thunk is a deferral of an expression's evaluation, why would said expression's evaluation happen more than once? The only thing which changes is *when* the actual evaluation happens.
Are thunks guaranteed not to leak out of the scope of the containing expression, so assignment is impossible? If they can leak, the thunk would be an object, and in Python "assigning" it to a "variable" actually just creates a reference. Evaluation could memoize the thunk's value ("evaluation only happens once") or reevaluate the thunk each time its value is requested. Either seems potentially surprising to me. Memoization makes sense if you think of the thunk as the closure of a computation that conceptually takes place at definition time. I'm not sure if in the use cases for thunks it really makes sense to "close" the thunk at evaluation time, but it seems like a plausible interpretation to me.