compiling to python byte codes

[Jeremy Bowers]

On Sun, 05 Sep 2004 23:20:59 +0000, Maurice LING wrote:

>> 
>> In your situation, I can promise you that it is *faster* to take the time
>> to learn about this stuff correctly then to try to power through it
>> without learning; it is one of those places in computer technology
>> where there are such powerful tools to help you that it is better to
>> learn how to use them then to kludge through. Unfortunately, it is too
>> large a topic to cover in a Usenet posting. 
> 
> I realised that there are powerful tools such as lex and yacc around 
> that can save me a lot of time. I'll be using PLY for my purpose.

That helps.

> I can only have the self-study options and good books on compiler 
> construction are rare. I am a molecular biologist by professional 
> training. There are things that are tough for me to understand and to 
> just find the answer about stacks vs register computers will take ages, 
> and I always appreciate people who do not treat me as an idiot. I'm sure 
> there are much more idiotic questions being asked in newsgroups.

I'm not sure if you feel I'm treating you as an idiot, or if you mean that
literally. Regardless, it isn't my intent. It is challenging because we
end up unable to share vocabulary.

> 
>> 
>> Stepping up a level, are you sure you can't just implement a C or Python
>> library and let people write their own programs in Python? You'll never be
>> able to match Python-the-language's feature set. 
> 
> What I'm doing is a special-purpose language (for modelling purposes).

OK, makes sense.

Now that you say you are using PLY, that at least gives us a common frame
of reference with code.  Take a look at the calc.py file that should have
been included with your PLY distribution.

It implements a simple calculator interpreter. It is an "interpreter"
because as it encounters the input, it is dynamically executing it. A
"compiler" would actually just store it as a tree, then later output it
into some other format without execution, which is what a C++ compiler
does, outputting the opcodes for the CPU.

Because of that extra step in the middle, "building a tree", a compiler is
typically harder to write than an interpreter. Getting the output right
can also be tricky, and a challenge to debug.

Thus, in terms of PLY, my suggestion has been to write an interpreter,
like calc.py, not a compiler. Unfortunately, like I said earlier, control
flow can be a pain, because you can't execute directly like calc.py does.

You want something else, though, that builds something and then executes
it later.