| Date: Fri, 4 Sep 2009 12:08:37 +0900 | From: =?ISO-8859-1?Q?Adrien_=22Pied=22_Pi=E9rard?= <[email protected]> | | 2009/9/4 Aubrey Jaffer <[email protected]>: | > 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. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
