[r6rs-discuss] Implicit parallel Scheme (was Re: Parallel-Scheme [was: Thoughts on Scheme's Future])

[Antonio Vieiro]

Some comments inlined below.

2009/9/16 Aaron W. Hsu <arcfide at sacrideo.us>

> On Sun, 13 Sep 2009 23:21:44 -0400, Aubrey Jaffer <agj at alum.mit.edu>
> wrote:
>
> >  | Date: Sun, 13 Sep 2009 21:14:01 -0400
> >  | From: "Aaron W. Hsu" <arcfide at sacrideo.us>
> >  |
> >  | On Tue, 08 Sep 2009 14:18:29 -0400, Aubrey Jaffer <agj at alum.mit.edu>
> > 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
> r6rs-discuss at lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20090916/6a4ec7ac/attachment-0001.htm