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

[Masklinn]

On 2014-03-06, at 08:29 , Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 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

No, it means the programmer wants the value to be strictly evaluated
(this is generally a space optimisation). It has no impact on program
behavior (assuming infinite resources, one issue of accumulating
thunks is the risk of OOM if they remain live but unevaluated).

> and "strictness
> analysis" is an optimization, not part of the language definition.  Am
> I missing something?

No? It just demonstrates that not everything is a thunk in haskell, there
are both thunks and strict values living around in the runtime, and
that's not visible in the type system.

>> 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?

I'm not sure I understand the question.

> If they can leak, the thunk would be an object

I think that's just one possible implementation, a thunk could also be
some sort of reference indirection, a tagged pointer, or a deeply
integrated proxy-ish 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.

Absolutely.

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

I find it the most *useful* definition: for the other one we already
have functions and I'm not sure thunks would have much use as shorter
arguments-less functions.

It also has the property that "client" code (code receiving thunks
without necessarily being aware of it) remains valid and unsurprising
in that

    a = foo
    b = foo
    assert a is b

remains true regardless of `foo` being a thunk (the only difference
being that if `foo` is a thunk it may remain unforced throughout).