[clpython-devel] CLPython for other lisps

[Willem Broekema]

On 2/4/07, Ignas Mikalajunas <ignas.mikalajunas at 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)))
        , 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