Heya, On Fri 16 Jul 2010 00:27, Brian Templeton <[email protected]> writes:
> BTW, as far as real-world Elisp compatibility goes, subr.el loads in one > of my branches: > > scheme@(guile-user)> ,L elisp > Happy hacking with Emacs Lisp! To switch back, type `,L scheme'. > elisp@(guile-user)> (load "/home/bpt/el/subr.el") > $1 = #t > elisp@(guile-user)> (let ((x nil)) (push t x) x) > $2 = (#t) > elisp@(guile-user)> (when t 42) > $3 = 42 > elisp@(guile-user)> (let ((x nil)) (dotimes (n 5) (push n x)) x) > $4 = (4 3 2 1 0) > elisp@(guile-user)> (nbutlast (list 1 2 3)) > $5 = (1 2) > elisp@(guile-user)> (delete-dups (list 3 2 1 1 2 3)) > $6 = (3 2 1) > elisp@(guile-user)> (number-sequence 1 10) > $7 = (1 2 3 4 5 6 7 8 9 10) > > This is Emacs's subr.el with no changes except removing the `add-hook' > definition (which really requires support for buffer-local variables). Very awesome!! > I've attached a partially-complete patch for unbound fluids Looks mostly good to me. Please separate out the parts that patch libguile/ from the parts that patch the elisp compiler, and send the libguile/ part to guile-devel, along with additions to fluids.test. > I've been reading old CL proposals regarding global lexical bindings, > and I think I now understand why this can't work in Guile. Previously I > wasn't considering the existence of a *global* environment, only lexical > and dynamic bindings, and hence I wasn't understanding the bindings > lookup order required for this. Scheme only allows LG lookup -- it looks > for variables in the lexical environment, then falls back to the global > environment. > > Globally-bound Elisp and CL variables are pervasively special, and > cannot be lexically bound. Globally-bound CL functions are pervasively > lexical (IIUC), and cannot be dynamically bound. Elisp bindings have > only global bindings, and cannot be lexically or dynamically bound. But > for Elisp function bindings, we need a globally-bound variable which can > be bound both lexically and dynamically. To allow dynamic shadowing of a > global lexical (but not pervasively lexical!) variable, the > implementation must do LDG lookup -- checking in the dynamic environment > after the lexical environment but before the global environment, which > is distinct from both the lexical and dynamic environments. But Scheme > doesn't *have* a true dynamic environment; it only simulates it by > storing fluids (i.e., indices into local dynamic state objects) in the > global environment, which of course means Guile Elisp can't have a > dynamic binding for a variable while retaining the global binding. > Therefore, it appears to me that Guile needs a real dynamic environment > if Elisp function bindings are to be non-special without breaking cl.el > FLET. I have to admit that I don't understand this fully. Cl.el's flet is a hack on top of emacs internals; while I do think we need to be very very compatible, this might be an instance where we might choose an alternate implementation. Surely it's possible to implement cl.el's flet via dynamic-wind and toplevel-set!? Cheers, Andy -- http://wingolog.org/
