Aubrey Jaffer escribió: > 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. >
I keep on thinking that this "Implicit parallelism" is the way to go fo the "Small Scheme", because as you say it removes bug-ridden thread management paradigms, that require you hiring gurus (http://herbsutter.wordpress.com/) to explain your team how to do things correctly. After all "These results argue that it is possible to get good parallelism in functional languages without adding explicitly parallel constructs. In fact, the lack of random access seems to be a bigger problem than the lack of parallelism." http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.3172 (There's a parallel SECD machine there, I think). The "Small Scheme" should allow (and not impose) this implicit parallelism. The R6RS Report has some rough edges that could be clarified/enhanced somehow for this to happen. Take, for instance: R6RS#Section 9.1: "Although the order of evaluation is otherwise unspecified, the effect of any concurrent evaluation of the operator and operand expressions is constrained to be consistent with some sequential order of evaluation. The order of evaluation may be chosen differently for each procedure call" And R6RS#A.9: "we use non-deterministic choice to first pick a subexpression to reduce only when we have not already committed to reducing some other subexpression." The report says there're two reasons for this behaviour (A.9): - A purely conventional one. - A "more technical one". Maybe it's time to review the "more technical one"... R6RS#Section 11.4.5: "A cond expression is evaluated by evaluating the test expressions of successive cond clauses in order until one of them evaluates to a true value (see section 5.7). When a test evaluates to a true value, then the remaining..." (That doesn't allow concurrent evaluation of test expressions) That could be rephrased as: "A cond expression is evaluated by evaluating the test expressions in some unspecified order. For the first test expression that evaluates to true, the remaining..." (Or something similar, that allows concurrent evaluation of test expressions, but that imposes that the first one evaluating to true, if any, is the one selected for the remaining stuff). Cheers, Antonio _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
