[r6rs-discuss] Parallel-Scheme [was: Thoughts on Scheme's Future]

[Aubrey Jaffer]

 | Date: Fri, 4 Sep 2009 12:08:37 +0900
 | From: =?ISO-8859-1?Q?Adrien_=22Pied=22_Pi=E9rard?= <axioplase+r6rs at gmail.com>
 | 
 | 2009/9/4 Aubrey Jaffer <agj at alum.mit.edu>:
 | > evaluation.  Thus, LET, LETREC, DO, and procedure calls would allow
 | > concurrent evaluation, while LET* and LETREC* would require serial
 | > execution.
 | 
 | I would not want to be the person deciding of the semantics of
 | 
 | ====START/THIS====
 | (define kont #f)
 | (define p (cons 0 0))
 | 
 | (define (inc!-car p)
 |   (set-car! p (+ (car p) 1))
 |   p)
 | 
 | (let ((x (call/cc
 |            (lambda (k)
 |              (set! kont k)
 |              1)))
 |       (y (inc!-car p)))
 |   (display y)
 |   (newline)
 |   (kont 'what?))
 | ====END/THIS====

Because the evaluation-order of LET is unspecified, the behavior of
this program is not specified by RnRS.  Its behavior would also be
unspecified in the parallel-Scheme I proposed.

 | I foresee discussions dealing with call/cc and concurrent
 | evaluation.  I haven't spent much time thinking about it, but one
 | could want the call of kont to respawn the computations of y, while
 | another may expect it to go to the rendez-vous when x and y are
 | bound, and a third person may want to reevaluate only those next in
 | the order decided by the implementation to spawn the concurrent
 | evaluations.

CALL-WITH-CURRENT-CONTINUATION should capture only the state of the
thread in which it was called.  It is up the implementation to make
continuations work with however many threads it spawns.

 | I am strongly in favor of parallelism/concurrency in Thing One, I
 | quite dislike "undefined behaviours", but I wonder how well it fits
 | the expectations of the mathematically versed designers.

Concurrent-evaluation is a slight generalization of
unspecified-evaluation-order.  It is the majority of the discipline
necessary to write parallel-Scheme programs (the other part being
serializing side-effects to shared state).

We've lived with unspecified-evaluation-order for decades.
Parallel-Scheme parlays UEO in existing code and coding practices into
concurrent evaluation with little modification.

I think this would be a great improvement over the difficult and
bug-ridden thread management paradigms of conventional languages.