pymacs! :-)

[François Pinard]

[Carel Fellinger]

> Like Marcin, I would prefer a lisp.fun notation.  And as many lisp names
> use funny characters like -, I suggest adding a [] interface as well,
> so we easily can access those weird emacs names like in

>    count = lisp["1+"](count)

Hello, Carel, and others.  Let me thank you, as well as those who wrote
various suggestions to me.  I tried to take good care of all ideas. :-)

Yes, I exactly added this (using square brackets) earlier today.  Calling
functions as per above was already in place since one day or two.  Also,
`lisp' itself can be used as a function to execute raw LISP code, like this:

     value = lisp("""
       ...
       POSSIBLY LONG LISP EXPRESSION
       ...
     """)

There is another interesting feature I put in today.  Consider:

     def procedure(object):
        lisp.setcdr(object, 17)

presuming that `object' has been given a cons-cell.  I wanted the `setcdr'
to act on the original OBJECT, and not on a copy.  So, `object' is a handle
to the LISP argument right in LISP space, whenever that argument is mutable.
A slight difficulty, easily solved, was to make sure those handles are
freed in LISP space in proper time, so they can be garbage collected.

On the debugging side, Python exceptions are properly reported as
tracebacks on the LISP side, while LISP errors occurring while Emacs is
serving Python are more summarily reported to Python and back to LISP.
This should not have adverse effects on later computations (I hope I did
it right).  One may add `print' debugging statements in Python, and with
a minimum of care, these will correctly appear in the `*Pymacs*' window.

Some handles could usefully be seen as sequences, I'll explore this.
Also, given handles and symbols have a `.value()' method, I'm thinking
of adding a `.copy()' method for handles, that would return an expanded
copy of the list as usable as possible on the mere Python side, without
further communication.  LISP proper lists could become Python tuples, LISP
vectors could become Python lists, and strings might loose their properties.

On summary, that project goes well, is nearly usable, and still small:
pymacs.el is 268 lines, pymacs.py 262 lines, and pymacs-services 11 lines.
The growth may be explained by the fact I added some documentation! :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard