Re: [Scheme-reports] Promises that force themselves

[Alan Manuel Gloria <almkglor@x>]

Okay, so my understanding is that:

> If no value has been computed for the promise,
> then a value is computed and returned.  The value
> of the promise must be cached (or "memoized") so
> that if it is forced a second time, the previously
> computed value is returned.

...should mean:

> If no value has been cached for the promise,
> the delayed expression is invoked.  Once that
> expression returns normally for the first time,
> its returned value must be cached (or
> "memoized") so that if it is forced afterwards,
> the value computed from the first return is
> given.

erk, the prose sucks, I suppose.  I guess it needs to be improved.

So basically, this can be said to mean that in a multithreaded
environment, because the promise's value gets cached only once the
expression returns for the *first* time, the delayed expression can be
executed in two separate threads simultaneously (i.e. an
implementation that allows that is R7RS-compliant).

So if my understanding is correct, I think I'd like to propose a
*proper* purely-functional promise as a R7RS-large library with the
assurance that the delayed expression will only evaluate once, in one
thread, with the possible drawback that promises that force themselves
have unspecified behavior.

--

Anyway, what would the following yield?

(define x 0)
(define p
  (delay
    (if (= x 5)
      x
      (begin
        (set! x (+ x 1))
        (force p)
        (set! x (+ x 1))
        x))))

(force p) => 10 (maybe?)
(force p) => ????

So: in case of a recursion, does it return the same value as the first
returning external (force p) - which yields 10 - or the same value as
the first returning internal (force p) - which (I think) should yield
5?

--

You know, I don't really know of a good use in applications of
re-entrant promises.  Laziness is hard enough with purity, having
mutation is a recipe for complexity.

I think that making re-entrant promises as unspecified behavior will
not actually affect *actual* applications/libraries, but I don't have
any actual data backing that idea.  I might try to hack a G-machine
implementation onto an actual application of laziness in Scheme if I
have time, ha.

Sincerely,
AmkG

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports