Michel Van den Bergh:

Is there any hope that CLPython will be ported to other lisps (gcl, clisp, sbcl)?

Sure. What are you waiting for? :-)

Ignas Mikalajunas:

I would like to see an asdf-installable CLPython running on sbcl too. I have somehow managed to add the asdf support and go around all the uses of lispworks specifc utility functions, but still was unable to complete the port since i don't know enough about CLOS MOP to finish the port.

Please wait a few days more, then CLPython will have a few sepate ASDF systems, and will be restructured into different packages and directories. There is still reliance on Allegro CL (not Lispworks), though.

Portability would really make it a lot easier to contribute to the project as now all the contributors are limmited to Lispworks users (an AFAIK most of the people contributing to open source common lisp projects are using - open source common lisp implementations).

Portability is not easy. Like, there is no portable way to use environments and custom declarations, while much compiler logic is currently based on that. Maybe other CL implementations offer functionality similar to Allegro; in that case there's hope to get it running on those implementations too. (Or someone could try to restructure the compiler; that probably won't be me as I'm happy with the current setup.)

Supporting other implementations is a wish, but not the main goal for me personally, so please join development if you want to realize it.

Having it asdf-installable would make it easier for others to integrate CLPython into their projects too.

Real soon.

- Willem

On 2/4/07, Ignas Mikalajunas ignas.mikalajunas@gmail.com wrote:

Kind of narrows the posiblities, as i am only familiar with non compiler specific common-lisp, and to make such a restructuring one would have to know ACL pretty well.

Not sure about that. If you really understand Python language semantics, you will be able to understand the CLPython compiler without knowing Allegro's internals. Allegro's support for environments and declarations make it possible to express compiler rules _easily_, but the rules themselves are not tied to the implementation.

Look for example at how a for-loop gets compiled. "for x in y: ..body..". This is parsed into '(for-in-stmt <stuff> ..body..). There is a macro for 'for-in-stmt, and the expansion includes ..body.. (which might be macroexpanded recursively).

The relevant point: the ..body.. in the expansion is surrounded by a custom declaration indicating the loop context:

(defmacro for-in-stmt (stuff &body body) `(.... (locally (declare (pydecl (:inside-loop-p t))) ,@body))))

Now upon encountering a "break" statement, the compiler checks if it is in a loop context, and if not raise a SyntaxError:

(defmacro break-stmt (&environment e) (if (second (assoc :inside-loop-p (sys:declaration-information 'pydecl e))) `(go :break) (py-raise '|SyntaxError| "BREAK was found outside loop")))

This is a simple but very powerful mechanism from a compiler-writer point of view: store the state in a declaration, and "lexically inner" macros can extract the state from the &environment. In the same way the compiler can keep track of local, global, and closed-over variables, and other state. But if you don't have Allegro-like environment functionality, it will be hard to express this as directly and cleanly.

Maybe you can keep such state using 'macrolet, but I don't want to try. I'll wait until other implementations include Allegro's or equally powerful functionality. Or until someone else scratches his personal itch and makes the compiler work in a non-Allegro implementation.

http://www.franz.com/support/documentation/8.0/doc/environments.htm http://www.lispwire.com/entry-proganal-envaccess-des

Some time ago you have mentioned the lack of contributors, and i think that depending on a commercial common-lisp implementation is one of the main factors limmiting the amount of developers who can work on the project.

Yep, I understand. On the other hand, the code runs fine in the free ACL express edition. That's "accessible enough" for me.

But I guess you have no more free time to port CLPython as I do, maybe even less.

No-one seems to have any time left these days, so the more reason to thank you for spending some of it thinking about CLPython :)

- Willem