Hi Ben,

Congratulations for sending the first post to CLPython-devel :-)

On 7/14/06, Ben midfield@gmail.com wrote:

fantastic work. i actually had tried in my spare time to do something like this, but using a hack where i used the AST python module to do the parsing. browsing the source, i see python functions -> lisp functions, python (meta)classes -> CLOS (meta)classes, etc. this is great!

It's the easy approach, and it more or less proves that Python as language is a subset of Common Lisp. Well, except for generators, as CL does not have a 'yield'-like operations.

what are your plans? have you tested it on any big python modules?

During development, the goal for the initial release was to be able to run the "Parrot benchmark" at a reasonable speed. The benchmark is described at http://www.sidhe.org/~dan/blog/archives/000219.html. As it covers a very large part of the language (and no external modules), it's a good test for complete language support.

Right now all the b*.py benchmark files can be run successfully on CLPython (with the exception that in b0.py there are some checks that fail, probably because they rely on the string representation of unprintable objects, which I don't find interesting to match 100% - a later version of CPython does not run it successfully either). Nevertheless, there are still some "basic" things missing (incomplete 'file' class; certain methods on dicts or lists missing).

i wanted to know what your thoughts were on porting to another lisp. i'd like to try to port to SBCL, which supports cltl2 environments, and i think there are some free yacc-like packages out there (none of which i've used, though.) in general imagine an implementation-specific compatibility layer will be needed, to bootstrap most python modules (regexps, network, etc.)

I had listed the two most important dependencies (in my eyes) on Allegro CL at the moment. I know about the existence of CL-Yacc; never used it, though I assume it should not be too much work to let CLPython play nicely with it.

As for the environments, I'd have to look more into that. Allegro CL has extended the CLTL2 environments, and I use ACL's functionality.

If it's possible to use custom declaration types (declare (pydecl ...)); and if it's possible to get the value of those declarations from an &environment variable in macros, that might be enough already for what the Python compiler needs.

You mention creating a compatiblity layer. Perhaps ACL-compat offers a lot of the desired functionality already?

great work!

Good to see you're interested :-)

- Willem