Some comments inlined below. 2009/9/16 Aaron W. Hsu <[email protected]>
> On Sun, 13 Sep 2009 23:21:44 -0400, Aubrey Jaffer <[email protected]> > wrote: > > > | Date: Sun, 13 Sep 2009 21:14:01 -0400 > > | From: "Aaron W. Hsu" <[email protected]> > > | > > | On Tue, 08 Sep 2009 14:18:29 -0400, Aubrey Jaffer <[email protected]> > > wrote: > > | > > | > That is why concurrency is entirely optional in > > | > Implicitly-Parallel-Scheme. At soon as compilers are smart enough, > > or > > | > threads are lightweight enough, IPS programs will reap the benefits. > > | > > | I'm not sure I understand something here. You seem to be > > | suggesting in this line of parallel Scheme thinking that somehow > > | the current Scheme standards explicitly exclude parallel > > | optimization of code, especially in areas where there is an > > | unspecified order of evaluation. > > > > The RnRSs explicitly require serial, if unspecified, order of > > evaluation. Scheme is thus a serial language. > > It explicitly requires that the behavior of the code be consisten with > some sequential evaluation of that code. > It explicitly requires that for procedure calls, but says nothing about concurrent evaluation of "let" nor about concurrent application of "map", and it says nothing about the behaviour of call/cc in concurrent environments. Those issues should be addressed in a future RnRS to allow (and not to mandate) concurrent evaluation of Scheme code. [...] > > > | Are you saying that the standards now don't permit parallel > > | optimizations to take place? It appears to me that they do, and > > | that Scheme is, even now, welcome to lead the forefront in > > | parallelization. > > > > Without a change to the language, Scheme would be no more parallel > > than FORTRAN-77. > > Outside of the issue of undecidability of determining the serializability > of parallel execution (if that's what you are asserting above) I can think > of no theoretical limitation on Scheme's semantics that prohibit parallel > execution in this area. Maybe I'm missing something? I'm not sure where > you are getting this requirement that Scheme be sequential by explicit > requirement. > I don't think there's a limitation either, there's some uncertainty though, that should be clarified. A simple statement specifying that all concurrent evaluation of Scheme code must be equivalent to a sequential evaluation in all cases (let bindings, procedure calls) and an explanation of how call/cc should behave on those cases would be clarifying. With those clarifications I think some Schemes out there would be able to exploit concurrency (for instance: by using a software transactional memory library that imposes that all concurrent changes to the environment are compatible with some undefined sequential order of evaluation). Note, again, that those clarifications in the report are aimed to *allow* and not to *impose* concurrent evaluation of Scheme. Cheers, Antonio > > 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 >
_______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
