[Compiler-sig] FYI: python/nondist/src/Compiler

[Jeremy Hylton]

>>>>> "MH" == Mark Hammond <mhammond@skippinet.com.au> writes:

  MH> Ideally p2c and this compiler could share some common framework.
  MH> Greg also mentioned this.  Ive got another project that was
  MH> based on P2C that Im working fulltime on (and Greg is helping) -
  MH> so that makes it 3 "compilers" we have going.  I bet that

Do tell! What is this other project?  At devday, Paul Dubois suggested
generating C++ code using CXX instead of straight C code; that struck
me as an excellent evolutionary path for p2c.

  MH> someone from the Types-SIG will jump on this for their
  MH> next-greatest type-inferencer :-)

That's my plan :-).

  MH> So, I had a think about reusing some of this framework for other
  MH> compilers, and come to the conclusion that not as much as I had
  MH> hoped can be shared ( But still enough that it makes it
  MH> worthwhile.  I can see the P2C directory stuff being shared,
  MH> along with the basic tree stuff you have.

It depends what the next steps for any of these compilers are.  The
code I have checked in is pretty primitive; there isn't much to share,
just because there isn't much there at all.

I hope to refactor the pyassem module and revise the code generator a
bit.  Instead of emitting straight-line code, with refs -- misnamed
StackRefs -- to other locations in the instruction stream, I would
like to generate code blocks that contain references to other blocks.
This intermediate representation would be more amenable to analysis
and still easy to generate bytecode from.

[Mark's suggested re-packaging:]
    compiler\__init__.py # Contains only: from compiler import compile
    compiler\compiler.py # Existing compile.py, less the first 1/4.
    compiler\tools\__init__.py # empty file
    compiler\tools\transformer.py, ast.py, etc
    compiler\tools\visitor.py # first 1/4 of existing compile.py

  MH> If you just change the COPYRIGHT file to reflect that it was
  MH> taken from the P2C project and renamed to "compiler.tools"
  MH> everyone should be happy I would think...

Sounds good to me; makes sense to move the visitor code to
compiler.tools.  This change okay with you, Greg & Bill?

  MH> Greg suggested we can reuse some of the name-lookup code, but Im
  MH> not too sure we can.  What Jeremy has is a faithful
  MH> implementation of the Python name bindings scheme, which is
  MH> perfect.  But any optimizing compiler (which includes P2C) and
  MH> any type inference systems will need to go a little bit deeper
  MH> than that - eg, P2C can optimize away certain builtin functions,
  MH> but to do that it needs to make the distinction between "global
  MH> cos Ive never seen it before" vs "global and Ive seen an
  MH> assignment".

I had hoped to do some dataflow analysis, but won't have time to work
on it in the near future.  It's also possible that Jon Riehl will
release his dataflow code soon, which might make sense to incorporate
as part of the standard tool suite.

Jeremy