On Wed, 2009-09-16 at 13:07 -0400, Aubrey Jaffer wrote:
> | Date: Tue, 15 Sep 2009 20:05:20 -0400
> | From: "Aaron W. Hsu" <[email protected]>
> | 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.
> "Outside of the issue of undecidability"? The Halting Problem is a
> fundamental constraint of code analysis! Ignoring the Halting Problem
> in creating a language specification is folly.
In this case, I think it actually can be ignored. Halting problem
notwithstanding, there's nothing to prevent external termination of
a computation that has exceeded a fixed time-and-resource limit.
This is, after all, engineering, in which limited information is
still usable, rather than mathematics, where limited information
is the diagnostic symptom of failure.
Proving a particular routine side-effect-free, then, has three
rather than two potential outcomes: It can be proven false, it
can be proven true, and the attempt can take long enough that it's
not worth continuing, in which the system may classify the
particular routine as "indeterminate."
If we treat indeterminate (and potentially unprovable) cases as
side effecting rather than side-effect free, it does not result in
any semantic error or program ambiguity w/r/t an "implicitly
parallelizable" dialect. At worst, it results in an opportunity
to parallelize going undetected.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
