Re: [Scheme-reports] Promises that force themselves

Hi,

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

Hello,

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.

Alex