The Visitor/Traverser

[Samuel Ytterbrink]

Hi, everyone!
Yesterday I talked a lot with Christian about the implementation of the new compiler. As a result I understood some things and I'm here to share.

At first I had a idea for making an intermediate state of the code that was closer to the actual text that needed to be generated. Even if this would be possible and make parts of the compiler cleaner and easier to understand it would probably make the whole compiler slower, because of all the objects that needs to be created. So for the time being we will just try to extend the current method with visitors that hands out the text, ready to be written to file.

The Traverser will be divided in to three Traversers: one for Python, one for JavaScript and a Multiplexer. The idea here is that we get three modes for the price of 1, or close to it. For this to work the intelligence of the Traverser, maintaining state and so on, needs to be in its general visit method. so that the state doesn't get scrambled if called from another object. I'm not sure of the last part and it would be good to get more input on the subject.

This layout of the classes and objects has lead to on of my new conclusions( i.e. haven't discussed it with any one yet). I think that we should move the current functionality of the visit method to a separate method visit->_visit(or __visit but that's evil, and results in name mangling). This way we could use inheritance to make sure that all Traversers _visit method is the same and still give freedom in there visit method that's doing all the hard stuff.

What do you think?

--
//Samuel Ytterbrink

[Ondrej Certik]

Hi,

I don't understand all the details from your email, but as long as the
compiler is kept quite simple, so that other people can fix bugs and
understand how it works, I am +1 to anything that gets the job done.

Ondrej

[Christian Iversen]

It will be. In fact, in my local branch I have 3 compilers:

- Javascript
- Python
- Multiplexer

This ensures that the compiler will be kept simple, since everything is
compartmentalized.

I also extended the py2js module, so expect the following structure in
the future:

py2js
py2js.decorator
py2js.compiler
py2js.compiler.python
py2js.compiler.javascript
py2js.compiler.multiplexer

The main module, py2js, contains a new Compiler class that will make it
much easier to use the compiler in real-world scenarios. It also
contains a utility function, py2js.compile(), to do a quick once-off
compilation for tests, etc.

--
Med venlig hilsen / Best regards
Christian Iversen

Sikkerhed.org ApS
Fuglebakkevej 88 E-mail: sup...@sikkerhed.org
1. sal Web: www.sikkerhed.org
DK-2000 Frederiksberg Direkte: c...@sikkerhed.org

[Ondrej Certik]

From what you say, it looks really cool!

Looking forward,
Ondrej

[Neppord]

Christian, can you upload your changes to a branch on your Github account so that I can view them while you are developing them. It would be good so that I don't create anything that collides with your plans.

Hope you have found my formatter class in the latest pull request.

//Samuel Ytterbrink

Skickat från min iPhone

[Ondrej Certik]

On Tue, Mar 8, 2011 at 4:23 PM, Neppord <nep...@gmail.com> wrote:
> Christian, can you upload your changes to a branch on your Github account so that I can view them while you are developing them. It would be good so that I don't create anything that collides with your plans.

Indeed, just push your patches into a branch, you don't need to send a
pull request. So that we can see what you are working on and plan
accordingly.

>
> Hope you have found my formatter class in the latest pull request.

Ondrej