Some comments inlined below.<br><br><div class="gmail_quote">2009/9/16 Aaron W. Hsu <span dir="ltr"><<a href="mailto:arcfide@sacrideo.us">arcfide@sacrideo.us</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Sun, 13 Sep 2009 23:21:44 -0400, Aubrey Jaffer <<a href="mailto:agj@alum.mit.edu">agj@alum.mit.edu</a>> wrote:<br>
<br>
> | Date: Sun, 13 Sep 2009 21:14:01 -0400<br>
> | From: "Aaron W. Hsu" <<a href="mailto:arcfide@sacrideo.us">arcfide@sacrideo.us</a>><br>
> |<br>
> | On Tue, 08 Sep 2009 14:18:29 -0400, Aubrey Jaffer <<a href="mailto:agj@alum.mit.edu">agj@alum.mit.edu</a>><br>
> wrote:<br>
> |<br>
> | > That is why concurrency is entirely optional in<br>
> | > Implicitly-Parallel-Scheme. At soon as compilers are smart enough,<br>
> or<br>
> | > threads are lightweight enough, IPS programs will reap the benefits.<br>
> |<br>
> | I'm not sure I understand something here. You seem to be<br>
> | suggesting in this line of parallel Scheme thinking that somehow<br>
> | the current Scheme standards explicitly exclude parallel<br>
> | optimization of code, especially in areas where there is an<br>
> | unspecified order of evaluation.<br>
><br>
> The RnRSs explicitly require serial, if unspecified, order of<br>
> evaluation. Scheme is thus a serial language.<br>
<br>
</div>It explicitly requires that the behavior of the code be consisten with<br>
some sequential evaluation of that code.<br></blockquote><div><br><br>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.<br>
<br>Those issues should be addressed in a future RnRS to allow (and not to mandate) concurrent evaluation of Scheme code.<br><br>[...] <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> | Are you saying that the standards now don't permit parallel<br>
> | optimizations to take place? It appears to me that they do, and<br>
> | that Scheme is, even now, welcome to lead the forefront in<br>
> | parallelization.<br>
><br>
> Without a change to the language, Scheme would be no more parallel<br>
> than FORTRAN-77.<br>
<br>
</div>Outside of the issue of undecidability of determining the serializability<br>
of parallel execution (if that's what you are asserting above) I can think<br>
of no theoretical limitation on Scheme's semantics that prohibit parallel<br>
execution in this area. Maybe I'm missing something? I'm not sure where<br>
you are getting this requirement that Scheme be sequential by explicit<br>
requirement.<br></blockquote><div><br><br>I don't think there's a limitation either, there's some uncertainty though, that should be clarified.<br><br>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.<br>
<br>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).<br>
<br>Note, again, that those clarifications in the report are aimed to *allow* and not to *impose* concurrent evaluation of Scheme.<br><br>Cheers,<br>Antonio<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
Aaron W. Hsu<br>
<br>
<br>
--<br>
Of all tyrannies, a tyranny sincerely exercised for the good of its<br>
victims may be the most oppressive. -- C. S. Lewis<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">r6rs-discuss mailing list<br>
<a href="mailto:r6rs-discuss@lists.r6rs.org">r6rs-discuss@lists.r6rs.org</a><br>
<a href="http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss" target="_blank">http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss</a><br>
</div></div></blockquote></div><br>