Re: Emacs Lisp and Guile

[Neil Jerram <neil@ossau.uklinux.net>]

Hello again - sorry for dropping this thread for so long.

[CC'ers - please say if you prefer not to be copied further]

>>>>> "Ken" == Ken Raeburn <raeburn@raeburn.org> writes:

    Ken> So, why were @fop and @bind needed in libguile anyways?  I was never
    Ken> clear on that.  Is it for performance, or is Scheme not up to the
    Ken> task?

Performance.  @fop (scm_m_atfop in C) does some pretty odd stuff, but
I think it could all be done in Scheme too.  @bind (scm_m_atbind) has
some special evaluator support, but again I think it could be done in
Scheme with set! and dynamic-wind.

    Ken> I wonder if it's the best choice.  I don't think encouraging people to
    Ken> support translation by starting with writing more C code for libguile
    Ken> is wise; we'll wind up with a libguile with random primitives for
    Ken> supporting translated elisp and perl and tcl and python
    Ken> and....  Personally, I'd rather see that support in Scheme modules.

Me too, as far as possible.  But I think it's acceptable to have a few
new primitives for convenience/performance, preferably abstracted
above the level of any single language (e.g. a general dynamic binding
primitive).

    Ken> One of my concerns in that area is with mixing Lisp dynamic bindings
    Ken> and Guile thread support.  If we want multi-threaded Lisp, do we pass
    Ken> around some sort of environment pointer, or call thread-aware routines
    Ken> to fetch current environment info?  Neil, does your code try to
    Ken> support multi-threaded Lisp?

No, it doesn't.

        Neil