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

[Jörg F. Wittenberger]

Am 02.11.2013 06:21, schrieb John Cowan:
> Jörg F. Wittenberger scripsit:
>
> > 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.
> The reason we didn't require this is that in order to cache the multiple
> values, in practice the implementation would have to put them into a
> data structure,

Sure it's easy to convert multiple value returns into a single value 
(e.g. a list) and back. Scheme _could_ be done without multiple values 
at all (the way you describe).  Just: multiple values are useful as an 
alternative to "(one shot) objects" and _may_ be implemented more efficient.

The downside of the r7rs decision to leave things open this way is what 
we observe right now with chicken: users desire the consistency between 
direct calls and delay/force and hence implement the "complicated" way 
using an intermediate list structure (even deconstructing the zero-value 
case as a special case but handling the one-valued case using the 
generic multiple value procedure C_values, which is according to my 
understanding less efficient - hence it would have been better to handle 
the one-value case special... but even talking about these details is 
more complicated than the source code ever would be) while at the same 
time portable programs must avoid dependencies on this behavior and 
implement the very same thing otop once again.  :-/
> > 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.
> That's the most plausible interpretation, yes.

While I dunno how the wording could be: I wish it was possible to at 
least suggest that in rXrs somehow.

>    But there are at least two issues: re-entrancy via call/cc and via threads 
> (which
> in some implementations may be the same).  We left that open,
> because it's not clear what the Right Thing is.

I'm short on wording too.  Wouldn't it be possible to require "all sorts 
of reentrance" to return the result of the first invocation?

Maybe even declare "at least threads" should do "the right thing and 
block" (if nobody can come up with a trick to handle call/cc too.

As things are, the situation is so inconsistent that, well it's not 
Schemish at all.  :-/

It's easier to provide test cases for all sorts of failures than an idea 
what force/delay are supposed to do.

In my code I try at least to cope with the multi-threaded case.  ... and 
to avoid dancing all time around export/toplevel issues ... I'm using a 
weird "delay*" instead of the intended "delay" everywhere. Ugly a work 
around.