[clpython-devel] plans (and porting)

[Willem Broekema]

Hi Ben,

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

On 7/14/06, Ben <midfield at 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