Hi, On Fri, Feb 8, 2013 at 11:50 AM, Alan Manuel Gloria <[email protected]>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
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
