public inbox for guile-emacs@sourceware.org
 help / color / mirror / Atom feed
From: Keisuke Nishida <kxn30@po.cwru.edu>
To: Kalle Olavi Niemitalo <tosi@ees2.oulu.fi>
Cc: guile-emacs@sourceware.cygnus.com
Subject: Re: Emacs Scheme interface
Date: Wed, 29 Mar 2000 16:57:00 -0000	[thread overview]
Message-ID: <m3og7xs29n.fsf@kei.cwru.edu> (raw)
In-Reply-To: <87g0tavmox.fsf@PC486.Niemitalo.LAN>

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

  reply	other threads:[~2000-03-29 16:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-27 22:51 Keisuke Nishida
2000-03-28  4:01 ` Kalle Olavi Niemitalo
2000-03-28 10:27   ` Keisuke Nishida
2000-03-28 11:37     ` Ken Raeburn
2000-03-28 23:06     ` Kalle Olavi Niemitalo
2000-03-29 16:57       ` Keisuke Nishida [this message]
2000-03-28 11:43 ` Kalle Olavi Niemitalo
2000-03-28 12:23   ` Keisuke Nishida
2000-03-29  2:33     ` Kalle Olavi Niemitalo
2000-03-29 17:09       ` Keisuke Nishida
2000-04-30 12:08         ` Kalle Olavi Niemitalo
2000-03-31 17:48 ` Keisuke Nishida
2000-03-31 22:42   ` Klaus Schilling
2000-04-01  9:02     ` Keisuke Nishida

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3og7xs29n.fsf@kei.cwru.edu \
    --to=kxn30@po.cwru.edu \
    --cc=guile-emacs@sourceware.cygnus.com \
    --cc=tosi@ees2.oulu.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).