[Chicken-hackers] clarification of multiple evaluation of promises

[Jörg F . Wittenberger]

Peter Bex has pointed out that my example in
http://lists.nongnu.org/archive/html/chicken-hackers/2013-05/msg00031.html
was not very clear about the problem at hand; let my clarify.

I wanted to show that we can proof the body of `(delay <expr>)` being
evaluated any random number of times. Depending on circumstances.

The code as posted includes only a single promise:

;; A single promise to test.
(define p
 (delay
   (let ((n (random 1000)))
     (seem-to-be-busy! hand)
     (begin
        (mutex-lock! workload-mux)
        (set! workload (cons n workload))
        (mutex-unlock! workload-mux))
     n)))

Reduced to the "actual work" it does, this would be

(define p (delay (random 1000)))

The `seem-to-be-busy!` is there only to simulate a real computation
to require wall-clock time and incur thread switched in between,
while the *workload*-related code underneath is there only for bookkeeping
to do the accounting of what's actually going on.

If there was no `seem-to-be-busy!`, the test would likely evaluate
the promise just once, as RxRS suggests as the lord's intention.

The value of `output` as reported will always *pretend* compliance
with the single-evaluation property of promises by returning the
*fastest* result seen - in each position of the list.

Playing with the constant numbers and the number of repetitions
caused by `hurry-up!` and `(define input (list p p p p p p))` it is easy
to find any random amount of elements in the final value of `workload`
between one (as in the promise "p" was evaluated just once and
the result properly cached) and n+1 with n being m*o where m
would be the number of repetitions in `hurry-up!` and o the
repetitions of p in the definition of `input`.

NB: Things would be even stranger, if we would cause the promise "p"
   to raise an exception for most results of (random 1000).

Thus `delay` and `force` behave as my intuition would suggest
*only* if `force` is called from the same thread, which produced
the promise using `delay`.


Best

/Jörg

BTW: To those concerned with r7rs: I really don't like that the draft
still leaves it undefined what the result of (force <promise>) is,
if the promise returns multiple values.  force/delay are not that
complicated to implement.  The way the r7rs draft is now, one would
still need to duplicate the definition in applications if one wanted
to be sure that multiple values are ok.


......