[Compiler-sig] AST observations

[Finn Bock]

[Jeremy]

>Finally, I should say that I don't have any strong attachment to the
>visitor code in the compiler package.  Nor do I have any strong
>attachment to the AST it defines.  I've started over with python.asdl,
>and I don't have any problems with starting over on a new visitor
>structure.  Let's find the ideas that work best for all our
>applications.  I'm probably going to want something visitor like
>implemented in C for the builtin bytecode compiler; I don't have any
>idea what that will look like yet.
>
>Efficiency was a non-goal for compiler.visitor.  I didn't even
>consider whether generating efficient Java code was possible.  (What
>would be the point of writing in the subset of Python that can be
>translated efficiently to Java? <wink>)

I see the wink, but the reason is portability between CodeCompiler.java
(which creates java bytecode) and SimpleCompiler.py (which generates
java sourcecode).

Both codegenerators have to do the same work and they uses a lot of the
same tricks to do it, and right now they use the same Visitor API. I
would not be happy if the two codegens had to use two different Visitor
API's just because one is written in java and the other in python.

I would rather not use the official and documented visitor pattern and
roll my own visitors (for both my uses), like you plan on doing for your
C bytecode codegen.

>We're kindof stuck with compiler package as it exists now, since it's
>a std part of 2.2.  But there's no reason it can't grow new classes
>that provide new or improved functionality.

Which begs the question: where do you intend to put the new AST classes
and the supporting functions? A new module in the 'compiler' package?

>On the subject of what the right visitor style is, ...

It might just be my expectation for a visitor pattern that is wrong and
visitor.py that is right. I believe I understood visitor.py when I read
your explanation.

regards,
finn