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

Re: [Scheme-reports] Promises that force themselves


On Fri, Feb 8, 2013 at 11:50 AM, Alan Manuel Gloria <almkglor@x> wrote:

R7RS draft 9 has the following example:

>  1: (define count 0)
>  2: (define p
>  3:   (delay (begin (set! count (+ count 1))
>  4:                 (if (> count x)
>  5:                     count
>  6:                     (force p)))))
>  7: (define x 5)
>  8: p
>  9: (force p)

force has the following description:

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

Arguably, the "first time" the promise is forced is at line 9 in the
example, and the "second time" is at line 6.  However, at that time
line 6 gets executed, no value has been computed *yet*, so presumably
this example follows the spirit of the law.

However, this example, I think, limits implementation options.

1.  The G-Machine technique for laziness, which black-holes unforced
promises at time of forcing, cannot be used, because it would have to
raise a "black hole encountered!" exception at line 6.

The G-Machine is a specific algorithm for a specific laziness
semantics which differs from traditional and current Scheme
laziness semantics.  The example in question has been in the
report since R4RS, so we can't change this without breaking
compatibility, and can't do that without good reason.  You'd have
to argue that the current semantics is "fundamentally flawed,"
which I think is a stretch.

2.  We have to be more careful of implementing promises in a
multithreaded environment.

We have to be careful of everything in a multithreaded environment.
The current assumption and existing implementation practice is that
you need mutex locks for most data-structures.  People tend to
get passionate about this and insist that certain data-structures must
be implicitly thread-safe (notably hash-tables, but everyone draws the
line differently).  There is interest in more sophisticated concurrency
techniques, but since Scheme is not purely functional the techniques
that are best for Haskell are unlikely to be best for Scheme.

Fortunately the small language has no threads.


Scheme-reports mailing list