Re: hey dude

[Andy Wingo]

Heya,

On Fri 16 Jul 2010 00:27, Brian Templeton <address@hidden> 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/