Re: Emacs Scheme interface

[Keisuke Nishida <kxn30 at po dot cwru dot edu>]

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> > > (lisp-eval '(current-global-map)).
> > 
> > I don't think it is a good interface.  It is harder to understand and
> > may not work in the future.
> 
> But at least it is easy to grep for "lisp-eval" when there is a
> better interface.  It is more difficult to convert from the
> current ((point)) syntax.

Either is not good.  That's why I think we should think of a better
interface soon.

> When importing a procedure, we should think of the value it
> returns.  Numbers and strings should be copied.  Lists perhaps
> too, if they are short and don't have to be modified in place.
> Keymaps and strange objects like buffers can be Lisp references
> for now; new Scheme types should be defined later.
> 
> I suppose things would be easier with Ken Raeburn's patches.  :-)

We can use GOOPS without changing the current C level interface,
as I wrote in another email; however, if we want to create GOOPS
objects automatically according to the type of return values from
Lisp functions, adding class information to Lisp references may be
convenient:

  (define (lispref->object lispref)
    (let ((obj (make (lispref-class lispref))))
      (set! (lispref obj) lispref)
      obj))

  (lispref->object (lisp-eval '(current-buffer))) => #<<buffer> ...>

Note that we cannot always rely on the value of lispref-class
since Emacs uses integers as the representation of characters.
We want to distinguish integers and characters in Emacs Scheme.
(Is there any way to do that correctly?)

(I guess we'd better always create Scheme integers instead of
references to Lisp integers for performance reasons.  This breaks
consistency, but that would be okay since programmers is discouraged
from using lisp-eval directly.  Maybe we should rename it %lisp-eval
or something.)

-- Kei