Home Original page

[Python-ideas] One more time... lambda function <--- from *** signature def.

Stephen J. Turnbull stephen at xemacs.org
Thu Mar 6 08:29:20 CET 2014 
Masklinn writes:
 > On 2014-03-05, at 22:51 , Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
 > > Masklinn wrote:
 > >> On 2014-03-04, at 23:31 , Greg Ewing <greg.ewing at canterbury.ac.nz> 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.
More information about the Python-ideas mailing list