3 ms·

I’m wondering what’s gained over writing your thunks as zero-argument functions (etc) in an eager language.

p4bl0 3y ago
If I understand correctly, here it is transparent. In an eager language a function needs to know whether it is given a value or a thunk, but here it can be both interchangeably (the thunk only need to have a type that says it returns a value of the same type as what could have been passed directly).
- soulbadguy 3y ago
  In theory, yes i would agree that they might be a different somewhere. But it's not clear (at least to me that) is this distinction maters in practice. I think the main point here would that a thunk is also a value. And most type system can already express "a computation which return Type X" by a value of type "() -> X". Adding side effect annotation, it seems to be that a pure function of type "() -> X" gives you very close to the same semantic. It's also unclear to me that one should want to allow both value and computation producing values to be used interchangeably. If the goal of CBPV is about better performance, then being able to mix and match both "kind" of value is probably not wise (at least without good compiler error messages), same as mixing type of values would break a type system.
- jayd16 3y ago
  Is it transparent? It seems like the goal is to be deliberate through explicit calls to thunk(). I guess you mean that a function parameter can be both a value or lambda.
tel 3y ago
There are a few differences, depending on how you evolve from the CBPV core, but basically other types may be eager or lazy. Functions can be eager (and thus statically know to represent an eager call tree) and sum types can be lazy (deferring choice). These distinctions are all available at the type level. To have thunking only arise from single unit-arg functions kind of depletes the logic of useful structure. But it’s not wrong to see it as an approximation.
samus 3y ago
Aren't thunks caching the result?

If I understand correctly, here it is transparent. In an eager language a function needs to know whether it is given a value or a thunk, but here it can be both interchangeably (the thunk only need to have a type that says it returns a value of the same type as what could have been passed directly).

soulbadguy 3y ago
In theory, yes i would agree that they might be a different somewhere. But it's not clear (at least to me that) is this distinction maters in practice. I think the main point here would that a thunk is also a value. And most type system can already express "a computation which return Type X" by a value of type "() -> X". Adding side effect annotation, it seems to be that a pure function of type "() -> X" gives you very close to the same semantic. It's also unclear to me that one should want to allow both value and computation producing values to be used interchangeably. If the goal of CBPV is about better performance, then being able to mix and match both "kind" of value is probably not wise (at least without good compiler error messages), same as mixing type of values would break a type system.
jayd16 3y ago
Is it transparent? It seems like the goal is to be deliberate through explicit calls to thunk(). I guess you mean that a function parameter can be both a value or lambda.

tel 3y ago

There are a few differences, depending on how you evolve from the CBPV core, but basically other types may be eager or lazy. Functions can be eager (and thus statically know to represent an eager call tree) and sum types can be lazy (deferring choice). These distinctions are all available at the type level. To have thunking only arise from single unit-arg functions kind of depletes the logic of useful structure. But it’s not wrong to see it as an approximation.

samus 3y ago

Aren't thunks caching the result?