[clpython-devel] Fwd: CLPython objects in a Lisp image

[Willem Broekema]

Link to message:
http://groups.google.com/group/comp.lang.python/msg/b72788cc5569d778

---------- Forwarded message ----------
From: metawilm at gmail.com <metawilm at gmail.com>
Date: Dec 16, 2006 12:54 PM
Subject: Re: CLPython (was Re: merits of Lisp vs Python)
To:


Paul Rubin wrote:
> metawilm at gmail.com writes:
> > >   a = 'hello'
> > >   a[0] = 'H'   # attempt to change first letter to upper case
> >
> > As CLPython mirrors Python semantics, this results in a TypeError. The
> > internal representation of an immutable Python string is a mutable Lisp
> > string, but there is no way you can actually modify it from within CLPython.
>
> How do you manage that?  The compiler can't check.  Is there some kind
> of special dispatch on the assignment statement instead of turning it
> into a setf?

Indeed, the assignment of subitems is dynamically dispatched, and
always goes via __setitem__ methods, as specified in the language. The
__setitem__ methods for strings and tuples raise exceptions. The ones
for lists and vectors could be translated into a simple (setf (aref ..)
..) and (setf (nth ..) ..), unless the index is actually a slice and
actually a subsequence must be replaced.

Now, the above description using __setitem__ methods is how it
apparently works, as observed from the outside. Internally there is a
generic function (setf py-subs) that does the work itself, skipping the
lookup and calling of __setitem__, if the object is a vector or dict.
(The user can call x.__setitem__ explicitly, so that method must exist
internally.)

Maybe you were thinking that CLPython, given Python code, outputs a big
pile of self-contained equivalent Lisp code that can be run
independently, and then CLPython is finished. Instead, only a small
amount of Lisp code is generated, but that code can only be run when
the CLPython environment is loaded. The generated code refers to that
environment, e.g. s[0] = 'x' is translated into a call to (setf
(py-subs ..) ..), and function (setf py-subs) is part of the CLPython
environment that must be loaded at run-time.

If you compile a Python function, the result is a (mostly) normal Lisp
function - its origin from the Python world does not really matter.
Also, all Python data structures are first-class Lisp data. Thus
CLPython objects live happily together with "normal" Lisp objects in
the same image.

And now we arrive at the most exciting part: other Lisp libraries can
be loaded in the same image, and we can create connections. Like, after
loading CLIM and defining how CLPython objects should be presented, we
should get a Python interpreter where classes are displayed graphically
and where you can inspect and modify them by mouse. Imagine that you
have interactively added a method to a class by dragging a function to
a class, then being able to right-click and select "write method",
which will write the definition of the method in the right place in the
class definition source code in your Climacs (CLIM-based Emacs) buffer.

That's the kind of features I have in mind, and the best thing is that
conceptually a lot of the work consists of connecting dots that already
out there. But as there are so many of them, a few extra pencils would
be quite welcome <wink>

- Willem