On Sun, 06 Sep 2009 05:16:19 -0400, Antonio Vieiro <[email protected]> wrote:
> 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. I would like to hear more about the technical reason for guaranteeing sequential evaluation. I believe that Chez Scheme actually does take advantage of this in some way, but I can't remember how. On the other hand, we should also keep in mind that while parallelizing in Scheme is a very nice idea and can yield theoretical benefits, at the moment, automated parallelization is nowhere near ready for use. Since it appears that industrial needs are the first on the list of things to address with Scheme, I'd say that more work on developing higher-level abstractions on concurrent programming processes, based on a thread model, should see a lot of attention, simply from the fact that automatic parallelization isn't going to be ready for a while. I am in favor of improving the ability of Schemes to do research in this area, of course, but I'd like to know how Scheme implementations right now take advantage of the sequential order mandate first. > 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). As others have pointed out, breaking COND is a bad idea. Someone should, however, consider creating a SRFI for parallel branching. This isn't easy to use in practice, because the paradigm of a normal COND doesn't go over to the parallel side at all. For example, testing for special subclasses before testing for general class membership breaks here. I don't think we're ready to standardize such things, because I haven't *seen* anything in the wild where these have been heavily studied across multiple implementations. This is not the place for innovating new Scheme technologies. That's where the implementations and users should come in. Once it is tested, then we can start examining parallelization in the standards. Maybe there are already some things that can be done in this regard, but not some of this major stuff like rewriting COND. Aaron W. Hsu -- Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. -- C. S. Lewis _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
