clpython-devel December 2006

clpython-devel@common-lisp.net

1 participants
5 discussions

[clpython-devel] Fwd: Not dead, bold future
by Willem Broekema 17 Dec '06

17 Dec '06

Link to message: http://groups.google.com/group/comp.lang.python/msg/7629a87adac6d0b1 ---------- Forwarded message ---------- From: Willem Broekema <metawilm(a)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

1 0

[clpython-devel] Fwd: CLPython objects in a Lisp image
by Willem Broekema 17 Dec '06

17 Dec '06

Link to message: http://groups.google.com/group/comp.lang.python/msg/b72788cc5569d778 ---------- Forwarded message ---------- From: metawilm(a)gmail.com <metawilm(a)gmail.com> Date: Dec 16, 2006 12:54 PM Subject: Re: CLPython (was Re: merits of Lisp vs Python) To: Paul Rubin wrote: > metawilm(a)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

1 0

[clpython-devel] Fwd: Choice of Common Lisp
by Willem Broekema 17 Dec '06

17 Dec '06

Link to message: http://groups.google.com/group/comp.lang.python/msg/fbfdc12acddc0f3f ---------- Forwarded message ---------- From: metawilm(a)gmail.com <metawilm(a)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 >>>

1 0

[clpython-devel] Fwd: Project silence and exposure
by Willem Broekema 17 Dec '06

17 Dec '06

Link to message: http://groups.google.com/group/comp.lang.python/msg/cd237cfa53c103e4 ---------- Forwarded message ---------- From: Willem Broekema <metawilm(a)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

1 0

[clpython-devel] Status update
by Willem Broekema 17 Dec '06

17 Dec '06

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

clpython-devel December 2006