From michel.vandenbergh at uhasselt.be Sun Feb 4 17:44:20 2007 From: michel.vandenbergh at uhasselt.be (Michel Van den Bergh) Date: Sun, 04 Feb 2007 18:44:20 +0100 Subject: [clpython-devel] CLPython for other lisps Message-ID: <45C61B74.7000508@uhasselt.be> Hi, Is there any hope that CLPython will be ported to other lisps (gcl, clisp, sbcl)? I have been advocating python as a language for maxima. Maxima (maxima.sf.net) is a very powerful GPL'ed computer algebra system that is written in CL. On top on the underlying CL implementation it also supports an algol like programming language ("the maxima language") which however has serious problems (you can check the discussions on the maxima mailing list about this). I think that it would be good to have python available as a second (algol like) language for maxima. Python is a widely known language with well understood semantics. It seems that CLPython would fit the bill but unfortunately the fact that it runs only on one CL implementation makes it impossible to use. For portability maxima has to run on all available CL implementations (and has admirably succeeded in doing so up to now). Best regards, Michel From ignas.mikalajunas at gmail.com Sun Feb 4 18:31:24 2007 From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas) Date: Sun, 4 Feb 2007 20:31:24 +0200 Subject: [clpython-devel] CLPython for other lisps In-Reply-To: <45C61B74.7000508@uhasselt.be> References: <45C61B74.7000508@uhasselt.be> Message-ID: > Is there any hope that CLPython will be ported to other lisps (gcl, > clisp, sbcl)? 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. 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). Having it asdf-installable would make it easier for others to integrate CLPython into their projects too. Ignas From metawilm at gmail.com Sun Feb 4 19:30:10 2007 From: metawilm at gmail.com (Willem Broekema) Date: Sun, 4 Feb 2007 20:30:10 +0100 Subject: [clpython-devel] CLPython for other lisps In-Reply-To: References: <45C61B74.7000508@uhasselt.be> Message-ID: 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 From ignas.mikalajunas at gmail.com Sun Feb 4 20:03:09 2007 From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas) Date: Sun, 4 Feb 2007 22:03:09 +0200 Subject: [clpython-devel] CLPython for other lisps In-Reply-To: References: <45C61B74.7000508@uhasselt.be> Message-ID: > 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. Sorry, holes in memory. > 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.) 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. > Supporting other implementations is a wish, but not the main goal for > me personally, so please join development if you want to realize it. 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. But I guess you have no more free time to port CLPython as I do, maybe even less. Ignas From metawilm at gmail.com Sun Feb 4 21:37:34 2007 From: metawilm at gmail.com (Willem Broekema) Date: Sun, 4 Feb 2007 22:37:34 +0100 Subject: [clpython-devel] CLPython for other lisps In-Reply-To: References: <45C61B74.7000508@uhasselt.be> Message-ID: On 2/4/07, Ignas Mikalajunas 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 ..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))) , at 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