From midfield at gmail.com  Fri Jul 14 17:12:35 2006
From: midfield at gmail.com (Ben)
Date: Fri, 14 Jul 2006 12:12:35 -0500
Subject: [clpython-devel] plans (and porting)
Message-ID: <9157df230607141012j2e2698f3m7bc479de0594006b@mail.gmail.com>

hi --

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!

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

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.)

great work!

Ben


From metawilm at gmail.com  Fri Jul 14 18:18:17 2006
From: metawilm at gmail.com (Willem Broekema)
Date: Fri, 14 Jul 2006 20:18:17 +0200
Subject: [clpython-devel] plans (and porting)
In-Reply-To: <9157df230607141012j2e2698f3m7bc479de0594006b@mail.gmail.com>
References: <9157df230607141012j2e2698f3m7bc479de0594006b@mail.gmail.com>
Message-ID: <f6bc9b490607141118t168d6365kbfe348ea12c80c59@mail.gmail.com>

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


From midfield at gmail.com  Sat Jul 15 18:12:04 2006
From: midfield at gmail.com (Ben)
Date: Sat, 15 Jul 2006 13:12:04 -0500
Subject: [clpython-devel] Re: clpython-devel Digest, Vol 1, Issue 1
In-Reply-To: <20060715160034.B261E28090@common-lisp.net>
References: <20060715160034.B261E28090@common-lisp.net>
Message-ID: <9157df230607151112x678d50e6ue099e28c509cf08d@mail.gmail.com>

> Hi Ben,
>
> Congratulations for sending the first post to CLPython-devel :-)

my interest in the project was to attempt to port the large number of
interesting and high quality pure python libraries out there to lisp.
seems like a worthwhile goal.  i would have expected other lispers to
realize there's a lot of low hanging fruit out there.

> 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.

presumably this can be simulated either with CPS or a state machine
(that's how C# does it, at least.)

> Right now all the b*.py benchmark files can be run successfully on

that's fantastic!

> 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.

it looks like the environment support in sbcl is somewhat rudimentary.
 in particular, there is no define-declaration.  i don't know if it
would be difficult to add.

however, franz has generously supplied a portable environments implementation

http://lispwire.com/entry-proganal-envaccess-des

which they claim works on sbcl.  it is LLGPL.

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

that's an idea.  another idea is to use the various proto-standards
that are floating around for things like network, fs, et cetera.

> Good to see you're interested :-)

unfortunately i'm supposed to be finishing a dissertation soon.  so i
don't have time myself in the short term.  but eventually i will have
time and hope to be able to help.

keep us informed!

regards, B


From metawilm at gmail.com  Sun Jul 23 07:21:29 2006
From: metawilm at gmail.com (Willem Broekema)
Date: Sun, 23 Jul 2006 09:21:29 +0200
Subject: [clpython-devel] public CVS available
Message-ID: <f6bc9b490607230021i64cefdebw9127a9a913fa40f@mail.gmail.com>

Hi everone, and thanks for your interest in CLPython.

The source code is available in a public cvs server. To check out the code:

export CVSROOT=:pserver:cvspublic at cvspublic.franz.com:/cvs-public login
cvs co python


- Wlilem