[r6rs-discuss] Implicitly Concurrent Scheme
Aaron W. Hsu
arcfide at sacrideo.us
Sun Nov 22 16:12:37 EST 2009
Hello Antonio,
--On Sunday, November 22, 2009 10:51:37 AM +0100 Antonio Vieiro
<antonio.vieiro at gmail.com> wrote:
> If, as Aaron states, there is no implementation or interpreter that has
> that particular optimization (evaluating stuff concurrently) then why
> does the restriction exist at all?
>
> If, as Aaron states, there is no proof of that concept, then why does the
> restriction exist at all?
The lack of implementations doesn't demonstrate anything besides the
lack of a demonstraated implementation of ICS that works. In other
words, ICS is not practically proven in real programs unless some clear
implementation has been demonstrated to be effective in a way that an
implementation enforcing the serializable restriction could never be in
practice.
> Aubrey has requested the restriction to be removed, so let's remove it.
> And if someone has something to say in *favour* of the restriction to be
> kept in the report then I'd like to see a serious reason for it to be
> kept (I haven't seen none yet).
>
> After all that's the spirit of Scheme: removing superfluous features and
> restrictions, isn't it?
Scheme places a *great* deal of restrictions on implementations, which
makes life easier on the user. These are not considered bad things.
Restricting the user is generally seen as a bad thing. Jcowan has
addressed this issue satisfactorily, but others have addressed removing
the serial evaluation restriction more directly:
[Some computations are] non-serializable: there exists a parallel
schedule whose final result cannot be achieved in any sequential
computation. In databases, for example, non-serializable transactions
are considered great evil, and the perpetrators are publicly flogged
(or ought to be). [1]
This restrictions ensures two things:
1) The behavior of the expression in question will never exhibit
behaviors that cannot be reproduced in a single-threaded environment.
2) The programmer need not constantly consider issues of threading for
every function call, which must happen in the case of ICS.
In other words, removing the restriction makes programs less clear, more
prone to problems, and hence, less reliable, without actually
introducing anything new for the user. This is all for the sake of
making it easier to concurrently execute procedure calls for the
implementors. I can't see how it is worth it.
Aaron W. Hsu
More information about the r6rs-discuss
mailing list