From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ken Raeburn 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 Message-id: References: <200003170249.TAA03077@aztec.santafe.edu> X-SW-Source: 2000-q1/msg00033.html Richard Stallman 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.