Re: [OT] code is data

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

.

Relevant Pages

  • Re: Source-to-source transformation: best approach?
    ... I don't know why TXL would be especially suited for source to source ... this for wide classes of language (in the sense that I have looked at ... its derivative, Stratego), and my tool, DMS. ... RecDescent for my long-term source to source transformation needs. ...
    (comp.compilers)
  • Re: SQL for presentation
    ... transformation could be done using SQL select statements. ... that you mean some language consistent with relational theory. ... HTML is a markup language. ...
    (comp.databases.theory)
  • Re: Integral and non-integral
    ... >> struct X ... should be allowed to write, in a header file, ... The question is why this is actively prohibited by the language. ... Except for the use of underscores this is also a transformation the ...
    (comp.lang.cpp)
  • Re: What was Noam Chomskys contribution to *LINGUISTICS*?
    ... We have a universal grammar ... > defining a universal language U, and all real language R can be produced ... > by a transformation, one for each language, that maps sentences of U into ... A transformation takes you from "Mary kissed John" to "John was kissed ...
    (sci.lang)