On Tue, Jul 11, 2006 at 09:59:12PM -0400, Audrey Tang wrote: > ?b 2006/7/11 ?U?? 7:33 ???AChip Salzenberg via RT ?g???G > >Now think about the alternatives if your goal is to have the table ready > >to go at runtime without any computational overhead at all. > > And if we can restrict :immediate using some security principal in the > future so it can only do things that are not destructive -- and always > yield the same result -- in other words, do not depend on the environment, > then this use would be totally fine.
But that's impossible, as you know well if you just think it through. 'Dependence on the environment' may not be a characteristic of mathematically perfect functional models, but it *is* a characteristic of *all* real programs running in the real world on real hardware. It cannot be avoided, no matter what changes we make and how carefully we try to create 'pure and ideal' computation. For example: What if the IEEE FP of the compilation machine differs slightly from the target machine, so that you get -0 instead of 0 or Inf instead of NaN? What if the Parrot versions of compiler and runtime differ slightly so that the C code behind multi sqrt(Float) isn't the same on the compiler as on the target machine? What if the CPU's been upgraded and the new Pentium suddenly knows how to do long division? What if we alter the hash ordering so the data structure building code produces different results? You think :immediate is a bug. It isn't. It's a messenger of Eris, and Fred Brooks is singing in its choir. I hear him now: "90% of debugging is answering various forms of the question, 'Which program is this?'" In short, to say that :immediate is unpredictable is to make a null statement, because in practice, all computation is unpredictable. -- Chip Salzenberg <[EMAIL PROTECTED]>
