> I don't see how generating byte code for a = 9; when seeing the > expression a = 3 + 6, would be a problem for non-functional > languages.
Most probably. But I don't see much code of that type that it would be worth optimizing for, either. The cost for re-evaluation such an expression doesn't really account for any performance problems you hit - in python, of course. See this: [EMAIL PROTECTED]:/usr/lib/python2.3$ python timeit.py -c "[4*5 for i in xrange(10000)]" 100 loops, best of 3: 5.5e+03 usec per loop [EMAIL PROTECTED]:/usr/lib/python2.3$ python timeit.py -c "[20 for i in xrange(10000)]" 100 loops, best of 3: 4.3e+03 usec per loop Now of course the longer the expressions get, the more time it costs - but how many long arithmetical expression of constant evaluation value do you have? > > I agree that things like [time.time() for i in xrange(10)] shouldn't > be pregenerated and that the problem is more complicated as I thought. > > But during compilation the compilor could do an anlysis of the code > do determine whether there are side effects or not. If the compilor > then would store a code in the byte code for functions that are > guaranteed side-effect free and only pregenerated objects generated > by expressions with no side-effect, some common subexpression > elimination could be done even in a non-functional language. This analysis would only be possible for the most primitive of examples, the reason beeing that due to the dynamic features syntactically equivalent expressions can have totally different semantics. So its not really worth the effort. -- Regards, Diez B. Roggisch -- http://mail.python.org/mailman/listinfo/python-list
