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

[Jörg F. Wittenberger]

Am 04.11.2013 06:17, schrieb John Cowan:
> "Jörg F. Wittenberger" scripsit:
>
> > 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.
> Yes, they may be when returned directly, but not when cached for later
> return.  In that case, allocating a data structure (even if it's
> never used again) is unavoidable.

Sure, but that's not the point I'm after.

For the sake of consistency I feel it's better to define `force` to 
return just what the delayed expression returned. Thus multiple values 
if that's been the thing.

Otherwise chicken users - and for sure other Scheme's too - are in the 
uncomfortable situation that writing portable code requires them to know 
that their implementation of choice will do "the right thing" but they 
still have to go to the trouble and double the implementation because of 
their intention to end up with portable code.

I feel that's bad.

Especially in the situation at hand, where we know: a) because of this 
possibly re-entry a modern implementation needs to unroll in constant 
space (additional code over the trivial case) and b) in some (hopefully 
near) future something should be defined how to handle concurrent use of 
`force`, which will likely require a similar trick.
> > 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.
> Threads are not defined in R7RS-small, and the only place we discuss them
> is in `parameterize`, where we explain that a value dynamically bound in
> one thread does not affect any other threads (a bare minimum requirement).
> Note that R7RS parameters can be rebound but can't be mutated, which was
> done specifically because some implementations copy the mutated value
> when forking a new thread and others do not.

Nevertheless they are a) mentioned and thus "in scope somehow" b) may be 
just refined call/cc, which takes us back to the question I can't 
answer: "can something be done to make sure delayed expressions are 
evaluated just once".

Note that there is a concept "set variables" (I came across it in "paxos 
at war" http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-593.pdf but I'm 
not sure that this is the origin) which is quite helpful when reasoning 
about parallel processing in general. This concept would perfectly map 
to Scheme's delayed expressions … if those where evaluated just once in 
any case.

Best Regards

/Jörg