public inbox for guile-emacs@sourceware.org
 help / color / mirror / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
To: rms@gnu.org
Cc: guile-emacs@sourceware.cygnus.com
Subject: Re: guile-emacs-0.1 released
Date: Fri, 17 Mar 2000 02:10:00 -0000	[thread overview]
Message-ID: <tx1k8j1aov2.fsf@raeburn.org> (raw)
In-Reply-To: <200003170249.TAA03077@aztec.santafe.edu>

Richard Stallman <rms@gnu.org> writes:
>       Symbols might be converted without waiting for
>     strings to be done, but the interaction of Lisp dynamic bindings and
>     buffer- and frame-local bindings and Scheme lexical bindings needs to
>     be worked out.  (IMHO, Scheme code should see Scheme behavior unless
>     it requests access to the current Lisp environment.
> 
> I don't think so.  That is not a useful behavior in the context of
> Emacs.  To get useful results, we need to make the normal ways of
> writing code access the local bindings of Emacs.

Which "normal ways of writing code"?

If people want to write elisp, it'll work just fine, with the expected
dynamic bindings and buffer-local variables and so on.

If people want to write Scheme to extend an application -- be it GNU
Emacs or GNU ld or whatever -- I think it should be Scheme, not
"Scheme except maybe for dynamic bindings if you're running Emacs".
Otherwise, what's the point of a supposedly common extension language
for different applications?  You wind up writing Scheme libraries
that'll work in lots of GNU applications except Emacs, or they'll work
only in Emacs....

IMHO, the right way to go is to allow both Scheme and Lisp
programming, with each one looking like its "normal" self, and odd
things happening only when you cross the boundaries.  We should keep
that as clean and easy to use as possible, of course, but I think
that's the place where any weirdness should be, and I fully expect
it'll be impossible *not* to have at least a little weirdness (e.g.,
the whole ()/#f/nil problem, and function slots that are part of elisp
but not scheme).

I think Keisuke's got the right idea -- simple functions available in
each language to manipulate what's on the other side of the split
between languages.

>     And then there's variables restricted to specific types, and with
>     side-effects in the C code.
> 
> These variables are just an implementation method, not a feature users
> depend on.  I'm sure we could manage to implement the code that uses
> these variables in some other way, if that will simplify matters by
> avoiding the need for a special feature for such variables.

I don't think they'd be hard to do, given the rest, they're just
things to keep in mind when figuring out how to do the rest.

  reply	other threads:[~2000-03-17  2:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-13 15:11 Keisuke Nishida
2000-03-14 12:46 ` guileapi.x problems [patch] Kalle Olavi Niemitalo
2000-03-14 13:20   ` Keisuke Nishida
2000-03-15 21:11   ` Ken Raeburn
2000-03-16  4:29     ` Kalle Olavi Niemitalo
2000-03-16  8:55       ` Keisuke Nishida
2000-03-16 16:57         ` Kalle Olavi Niemitalo
2000-03-17  9:55           ` Keisuke Nishida
2000-03-15 21:07 ` guile-emacs-0.1 released Ken Raeburn
2000-03-16 12:29   ` Keisuke Nishida
2000-03-16 18:50   ` Richard Stallman
2000-03-17  2:10     ` Ken Raeburn [this message]
2001-01-07  9:13       ` Richard Stallman
2001-01-07 13:28         ` Ken Raeburn

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=tx1k8j1aov2.fsf@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=guile-emacs@sourceware.cygnus.com \
    --cc=rms@gnu.org \
    /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).