[pypy-dev] Python parsers...

[Armin Rigo]

Hello,

On Fri, Aug 01, 2003 at 01:03:50PM +0200, holger krekel wrote:
> - there seems to be a chicken-and-egg problem with the implementation
>   of a Bytecode instance 'B': it needs to be compiled, too.

I think we should not worry about this problem. Currently we need CPython for
bootstrapping. When we can create (using CPython) a stand-alone PyPy that can
interpret regular Python code, then we can simply switch from CPython to that
PyPy to bootstrap the next versions of PyPy.

> > A lot of this technology is key to the Basil project as I was going to 
> > build a control flow and data flow analysis toolset for C/C++/Python.
> 
> Here Armin or others need to chime in.  The whole abstract
> interpretation/annoated object space thing is still somewhat opaque to me. 

There is certainly room for both approaches to code analysis: the syntax one
(a parse tree walker is cool), and the semantic one, which is the purpose of 
the annotated object space (abstract interpretation).

The two approaches complete each other. The first one is suited to high-level
analysis of the code, close to the source; we can reason about the constructs
used in the source. It is good to check global properties of the code, or to
do control flow analysis. The second one is closer to the actual execution,
and I'd say it is more suited for things like type inference or data flow
analysis because we follow step by step what the interpreter would do with
real data, at a low level.

In other words, abstract interpretation is excellent for questions like "what
would the interpreter do at run-time if...". It cannot answer questions about
the source.

Our "annotation object space" tries to do type inference, and I thought we
could then use another object space to translate the code to low-level C code
using the information previously inferred. Now that I think about it it may be
even nicer to combine the semantic analysis of the type inference with a
*syntactic* translator to keep the higher-level "feeling" of the source code
in C; not that it is really needed in our particular case, but I guess some
would like it (e.g. for a Pyrex-like project).


A bientôt,

Armin.