From metawilm at gmail.com  Sun Dec 17 10:34:47 2006
From: metawilm at gmail.com (Willem Broekema)
Date: Sun, 17 Dec 2006 11:34:47 +0100
Subject: [clpython-devel] Status update
Message-ID: <f6bc9b490612170234k411084dch1512f763e379eb5e@mail.gmail.com>

Dear clpython-devel members,

It has been quiet on this mailing list for a long time. I'd like you
to know that the project is stil alive, and that there is still
progress, albeit slowly.

On comp.lang.{lisp,python} there was a discussion about Python versus
Lisp. CLPython was mentioned, and I wrote a bit about the current
status and the future. I'll forward the three messages I wrote there,
as it's about time you get an update, and so that people new to the
project will find it in the list archive. Sorry for the duplication if
you read the thread in the newsgroup already.

If anything is unclear about how things currently work, or if you have
suggestions for future directions, then please reply - that's what
this list is for! :)

Cheers,
- Willem


From metawilm at gmail.com  Sun Dec 17 10:37:46 2006
From: metawilm at gmail.com (Willem Broekema)
Date: Sun, 17 Dec 2006 11:37:46 +0100
Subject: [clpython-devel] Fwd: Project silence and exposure
Message-ID: <f6bc9b490612170237ie70dc40pc53bfe8d7033e069@mail.gmail.com>

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

---------- Forwarded message ----------
From: Willem Broekema <metawilm at gmail.com>
Date: Dec 14, 2006 8:01 PM
Subject: Re: CLPython (was Re: merits of Lisp vs Python)
To:


Paul Boddie wrote:
> What would it take to get Python people more interested in it? I've
> been monitoring the site [1] and the mailing list [2] for some time,
> but nothing particularly visible seems to be happening.

Well, judging from the reactions on blogs to the initial announcement
here, quite some people have heard about it and seem interested. But
that didn't result in more people hacking on it, which is unfortunate.

I guess in part it's because there are not that many people really into
both Python and Lisp, and those who are might not find this an
interesting project because there is nothing "wow" to show, yet.

So you are right about the project silence. Right now it's a one-person
pet project, and progress is slow. But I'm already quite happy about
the current state: stable, usable, and fairly complete.

As for more exposure: I'd prefer to wait with big announcements until
there are really interesting things achieved.

Thanks a lot for your interest and comments!

- Willem


From metawilm at gmail.com  Sun Dec 17 10:39:41 2006
From: metawilm at gmail.com (Willem Broekema)
Date: Sun, 17 Dec 2006 11:39:41 +0100
Subject: [clpython-devel] Fwd: Choice of Common Lisp
Message-ID: <f6bc9b490612170239k6787c4betec01eb3b9ff8e59@mail.gmail.com>

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

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


Paul Rubin wrote:
> I thought it was of some interest though I'm a little surprise by the
> choice of CL rather than Scheme as a target.

In many aspects Python is a subset of CL. In CLPython, exceptions are
Lisp conditions with a custom metaclass (strictly spoken not portable
CL), Python (meta)classes are CLOS classes, methods are implemented
using hashtables and functions and CLOS generic functions, strings and
numbers have direct equivalents, hash tables implement dicts, Python
functions are funcallable CLOS instances, tuples and lists are Lisp
lists and vectors, generators are closures. Thus a great part of
implementing CLPython consisted of connecting already existing dots. I
found that quite amazing.

> I'm still not sure about the mapping of Python strings to Lisp strings.
> What happens with the following in CLPython?
>
>   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.

Now in some cases modifying strings is dangerous (e.g. when stored in
an instance dict to represent an attribute), but in other cases it can
be completely safe. And modifying strings is a normal Lisp feature, so
it sounds strange to disallow it at all times. Maybe there should be a
way for the user to declare that he knows what he is doing, and does
not want the Python implementation to be "crippled" w.r.t. the host
language. Normally you start the CLPython interpreter using (repl);
maybe something like this would allow dangerous statements:

  (let ((*strict-python-semantics* nil))
    (repl))

Oh, and there is actually one way to modify Python strings in the
interpreter, namely using Lisp commands:

PYTHON(12): (repl)
[CLPython -- type `:q' to quit, `:help' for help]
>>> s = "abc"
'abc'
>>>  (setf (aref _ 0) #\x)
#\x
>>> s
'xbc'
>>> type(s)
#<class PY-STRING @ #x10575342>
>>> type(s) == str
1
>>> s
'xbc'
>>>  (inspect _)
A NEW simple-string (3) "xbc" @ #x11548f6a
   0-> The character #\x [#x0078]
   1-> The character #\b [#x0062]
   2-> The character #\c [#x0063]
[1i] PYTHON(13): :ptl
>>>


From metawilm at gmail.com  Sun Dec 17 10:41:17 2006
From: metawilm at gmail.com (Willem Broekema)
Date: Sun, 17 Dec 2006 11:41:17 +0100
Subject: [clpython-devel] Fwd: CLPython objects in a Lisp image
Message-ID: <f6bc9b490612170241m5deb186aqc0e4328405bfd327@mail.gmail.com>

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


From metawilm at gmail.com  Sun Dec 17 10:42:56 2006
From: metawilm at gmail.com (Willem Broekema)
Date: Sun, 17 Dec 2006 11:42:56 +0100
Subject: [clpython-devel] Fwd: Not dead, bold future
Message-ID: <f6bc9b490612170242j5a9b2b24q9ec7d8557200da23@mail.gmail.com>

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

---------- Forwarded message ----------
From: Willem Broekema <metawilm at gmail.com>
Date: Dec 13, 2006 8:28 PM
Subject: Re: merits of Lisp vs Python
To:


Paul Rubin wrote:
> Does this count as a "children of a lesser Python"?

This sounds like a quite derogatory first question. CLPython is not a
dead and abandoned project, nor is execution speed its main goal, nor
are Python semantics bended anywhere (it can run the Pie-thon
benchmark). Sure, some recently introduced language features are
missing, but with just a little effort that's solved...

Moreover, in Common Lisp source code analysis and manipulation can be
expressed easily. CLPython thus provides ample opportunities to analyze
type inference or caching schemes. Most of that is unexplored
territory, I think. I like the journey so far.

> How does clpython implement Python's immutable strings, for example?

Normal Python strings are represented by normal Lisp strings. Instances
of subclasses of 'str' are represented by CLOS instances. That's for
performance reasons. This dual-representation aspect is nicely hidden
behind macros, so that even in the code of CLPython itself there's no
need to worry, or even know, about it.

Why not take a look in the code -- I'll be happy to explain things.

- Willem