Re: [Chicken-hackers] [PATCH] R7RS delay/force/delay-force

[Jörg F . Wittenberger]

Hi all,

prompted by Evan's message I just read r7rs once again.

There's something, which IMHO needs to be discussed/clarified and the 
decision documented somehow.

Rather uncontroversial: r7rs says "the result of a delayed expression 
returning multiple values is unspecified". Hence it's OK to actually return 
multiple values (as I'd prefer r7rs should have explicitely required). The 
downside is that a portable program must not depend on this to work.


In contrast to the kinda related topic of parameter objects, r7rs is a bit 
ambiguous about the effect of delayed expressions being forced multiple 
times.

It specifies "if it is forced a second time, the previously computed value 
is returned". This _could_ (and IMHO _should_) be understood as if the 
delayed expression must only ever be evaluated once.

However it _could_ also be understood in a little less desirable and more 
complicated way: "once the evaluation of the expression has consummated, it 
must not be evaluated again".

The difference becomes apparent in multithreaded context when a promise is 
forced a second time from a second thread. In the former case (as I'd 
prefer to read the r7rs) the second call to force must return the result 
from the first call, while the latter interpretation would allow both calls 
to force to return different values.

(BTW: a second, related question would concern the number of evaluations if 
the delayed expression would raise an exception. Should the second call to 
force retry?)

Best regards

/Jörg

Am 31.10.2013 09:07, schrieb Evan Hanson:
> Hi all,
>
> Here are two lazy patches.
>
> The first one just fixes the types.db entry for `force` so that it
> correctly allows multiple return values.
>
> The second modifies `force` and adds R7RS's `delay-force` to provide
> R7RS/SRFI 45-style lazy semantics, meaning "delay-forced" promises are
> peeled in constant space. In this case, a forced promise may now act as
> a box for another; otherwise, they behave similarly to before. 
>
> (This second patch seems useful enough to me to go in core, and it was
> easier to add there, but if you think it should go in the egg instead,
> let me know.)
>
> Cheers,
>
> Evan