>> While the _result_ of a transformation might be a less efficient piece of >> code (e.g. introducing a lock around each call to enable concurrent >> access), the transformation itself is very - if not totally - static - > > really ?
See below. > Nope, it's runned each time the module is loaded (with 'loaded' distinct > from 'imported') - which can make a real difference in some execution > models... I already mentioned that latency. If it for whatever reason really becomes important, it would be the best to cache the result of the transformation. Which would BTW eliminate any complexity driven runtime penalty - regardless of the tool used. So - loading time is _not_ an issue. And I spare you the premature optimization babble... :) >> So except from a start up latency, it has no impact. > > Having a high startup latency can be a problem in itself. See above. > But the problem may not be restricted to startup latency. If for example > you use a metaclasse and a function that *dynamically* creates new > classes using this metaclass, then both the class statement and the > metaclass code transformation will be executed on each call to this > function. This is an assumption I don't agree upon. The whole point of the OPs post was about creating DSLs or alter the syntax of python itself. All that to enhance expressiveness. But we are still talking about CODE here - things that get written by programmers. Even if that is piped through so many stages, it won't grow endlessly. Runtime (runtime meaning here not on a startup-phase, but constantly/later) feeding of something that generates new code - I wouldn't say that is unheard of, but I strongly doubt it occurs so often that it rules out tree transformations that don't try and squeeze the latest bit of performance out themselves. Which, BTW, would rule out python in itself as nothing beats runtime assembly generation BY assembly. Don't you think? > The whole point of a code transformation mechanism like the one Anton is > talking about is to be dynamic. Else one just needs a preprocessor... No, it is not the whole point. The point is "" The idea is that we now have a fast parser (ElementTree) with a reasonable 'API' and a data type (XML or JSON) that can be used as an intermediate form to store parsing trees. Especially statically typed little languages seem to be very swallow-able. Maybe I will be able to reimplement GFABasic (my first love computer language, although not my first relationship) someday, just for fun. """ No on-the-fly code generation here. He essentially wants lisp-style-macros with better parsing. Still a programming language. Not a data-monger. Diez -- http://mail.python.org/mailman/listinfo/python-list
