Christopher Smith wrote:
The reason would be that the loop might have side effects, and said side
effects might impact subsequent iterations.
... added to the fact that many current languages make such side-effects
difficult to determine. Things like having aliases into the data
structure, multiple user-managed threads with access to that memory, etc.
There was a language called Hermes (which came from NIL) which had a
data structure like a SQL relational table - a possibly-ordered array of
structures, if you would. The instructions that looped over the array
were defined to loop over an unmodified version of the array. Hence, you
could insert and delete rows without disrupting the iteration.
Essentially, if necessary, the object code would copy the array to a
temp and loop over that, letting you frob the new array. Of course, if
you didn't do things like look forward and backward in the array, the
compiler could tell that and didn't create the temp.
That's the sort of thing I expect the people who are jonesing for
massively-parallel cores right now wouldn't accept as having sufficient
performance, even if you showed them otherwise, in much the same way
many people fight against things like array bounds checking even if a
well-designed language can eliminate 95% of the array bounds checks that
you wouldn't put in your hand-crafted code anyway.
--
Darren New / San Diego, CA, USA (PST)
His kernel fu is strong.
He studied at the Shao Linux Temple.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
