[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jörg F . Wittenberger
Subject: Re: [Chicken-hackers] [PATCH] R7RS delay/force/delay-force
Date: 31 Oct 2013 15:30:49 +0100

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


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]