[r6rs-discuss] Implicitly Concurrent Scheme
antonio.vieiro at gmail.com
Sun Nov 22 04:51:37 EST 2009
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?
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?
Aaron W. Hsu escribió:
> Hello Aubrey,
> --On Thursday, November 12, 2009 02:21:50 PM -0500 Aubrey Jaffer
> <agj at alum.mit.edu> wrote:
>> I am suggesting the following restriction be *removed* from the
>> "Procedure calls" section of RnRS:
>> _Note:_ Although the order of evaluation is otherwise unspecified,
>> the effect of any concurrent evaluation of the operator and
>> operand expressions is constrained to be consistent with some
>> sequential order of evaluation. The order of evaluation may be
>> chosen differently for each procedure call.
> It has been argued why this is a bad idea. In my limited knowledge,
> there is not a proof of this concept. Maybe I'm missing it or have
> missed it, but is there some implementation or interpreter which has
> this particular optimization (obviously, this can't be done in the
> general case right now and still comply with Scheme specifications, but
> that's beside the point here) that demonstrates consistent general
> improvements in execution time on programs for which it would be
> completely intractible or far too slow to do analysis of the programs?
> Aaron W. Hsu
> r6rs-discuss mailing list
> r6rs-discuss at lists.r6rs.org
More information about the r6rs-discuss