[OT] code is data

[bruno at modulix]

Diez B. Roggisch wrote:
> bruno at modulix wrote:
> 
> 
>>Diez B. Roggisch wrote:
>>
>>>>>because lots of people know how to describe XML transformations, and
>>>>>there are plenty of tools that implement such transformations
>>>>>efficiently ?
>>>>
>>>>
>>>>Efficiently enough for dynamic (runtime) use ?
>>>
>>>
>>>Using XML-transformation for AST manipulation isn't my first choice
>>>either - yet efficiency concerns aren't really the point here - after
>>>all we're talking about generating code,
>>
>>I thought we were talking about *transforming* code - just like one uses
>>metaclasses to transform a class definition, or @decorators to transform
>>a function definition...
> 
> 
> Yes we were. So where does the runtime efficiency you mention come in to
> play?

class transformations via metaclasses and function wrapping does happen
at runtime - when the class or (decorated) def statements are eval'd.
This is not the same as having a distinct preprocessing phase that would
write a new .py file.

> 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 ?

> and
> usually only run once. 

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...

> So except from a start up latency, it has no impact. 

Having a high startup latency can be a problem in itself.

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.

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...

> So if for whatever
> reason XSLT is someones favorite method of AST-transformation because it
> fits her mindset - perfect. As I said: it wouldn't be mine either, but I
> can't see your concerns about efficiency. 

cf above.

> And XSLT certainly is suited for tree manipulation, so it might be that it
> would be good for e.g. recursivly stripping type annotations of some kind
> (think of e.g. type-verifying decorators that you want to get rid of for
> production.)
> 
> Diez


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"