[Python-Dev] Prothon on CPython intrepreter? [PROTHON]

[Brett C.]

Mark Hahn wrote:

[SNIP]
> I'm sure you've heard the joke that ends with "we've established you're a
> whore, now we are just haggling over the price".  If I can compromise
> Prothon for .Net, why can't I compromise it some more for CPython?  So I am
> thinking of doing a Prothon implementation in CPython before doing the .Net
> version.  I will get a library and community fast like I would have with
> .Net.  
> 

I am personally very glad to hear this!

> This CPython->.Net->CProthon roadmap will get Prothon out quickly and slowly
> easy my wild ideas for the interpreter into Prothon.  It will also make
> CPython a multiple language VM for the first time.
> 
> So, I'll finally get to some questions:
> 
[SNIP - question for Guido]

> 2) Lenard Lindstrom said he thought I could "Add some extra byte code
> instructions to handle Prothon's distinct scoping rules and implement
> prototypes using PyType_Type".

That is definitely possible.  If you look at the opcodes that currently 
exist (http://www.python.org/dev/doc/devel/lib/bytecodes.html for the 
in-dev docs; doesn't list LIST_APPEND or NOP, though ... Raymond, you 
planning on documenting these, or should I file a bug report?), there 
are opcodes for loading from locals, globals, names (when you don't know 
which scope), and cells (closure stuff).  Basically the opcode just 
specifies where to look in the code object for the value.  So yes, you 
could emit another opcode if you needed to for scope and you made the 
appropriate changes to the code object if you need other fields.

> He also said "All attribute accesses would be
> through a special attribute handler method".  I don't know the Python
> interpreter code yet, but does this sound workable to everyone?  It doesn't
> have to be Python compatible.
> 

Well, all attribute access goes through descriptors already (if I 
remember correctly from PyCON 2003's sprint).  You could just change the 
default descriptor to do what you want.

> 3) Could Tim Peter's welcome offer to Prothon here on Python-dev be
> stretched to include the many questions I would have when modifying CPython?
> In other words would this project be welcomed as a sandbox for Python or
> would it be an unwelcome drain on your limited resources?
> 

=)  You are are free to ask, just don't be floored if you are warnocked 
on occasion (warnocking, since I have only heard this in the Perl world 
form the perl-6-internals list, is when a message gets no response).  I 
personally have no issue and actually welcome the discussion since it 
could help with improving CPython with new ideas.  And this is coming 
from someone who will have to read the emails.  =)  I know I am 
personally willing to answer your questions.

I do have a piece of advice before you delve into this too deeply, and 
that is to consider looking at the AST branch (tagged as ast-branch in 
CVS).  Jeremy Hylton has been leading a rewrite of the compiler to take 
the concrete syntax tree, generate an AST for it, and then emit opcode 
from that.  It is *much* easier to use than how compile.c works now.  It 
also, in my opinion, makes things clearer by breaking up compilation 
into more, smaller steps.  It isn't in the main trunk yet, but it will 
be someday (I personally plan to work on it once my thesis is done so 
that I can hopefully integrate my work into the core more easily and it 
is now tradition for some people to sprint on it at PyCON =) .

Who knows, you might be able to just generate your own version of the 
AST or just have a different compiler for the AST itself and thus cut 
down and code duplication.

-Brett