[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Lisp and Guile
From: |
Neil Jerram |
Subject: |
Re: Emacs Lisp and Guile |
Date: |
05 Nov 2002 23:28:19 +0000 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
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 <address@hidden> 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
- Re: Emacs Lisp and Guile,
Neil Jerram <=