Re: Dynamic loading progress

["Stephen J. Turnbull" <stephen@xemacs.org>]

Stephen Leake writes:

 > > Er, because it *is* Emacs code?  
 > 
 > That was my initial view as well, because I new I needed fast
 > performance for my particular use case.
 > 
 > But I suspect some (most?) modules will be added just to provide a lisp
 > interface to some external library; the authors will see that as part of
 > their lisp code, not part of Emacs core.

Which is what I described and you called "conventional".  But that's
*not* what Daniel is exercised about.

 > One reason Emacs succeeds is because lisp is so forgiving; module
 > developers will expect the Emacs module API to be similarly
 > forgiving.

Yeah, and they expect a pony too.  The module API will be C, which is
not a forgiving language.  Lisp forgiveness is possible because it's
backed up by the use of longjmp, you know.

 > > In the relatively rare case that you have a way of passing a callback
 > > into Lisp to the library, you either program very defensively in the
 > > Lisp, 
 > 
 > Always a good idea anyway, at least until thorough testing is done.
 > 
 > > or just wrap the whole thing in a condition-case (such as
 > > ignore-errors) before passing it to the library.
 > 
 > What is the downside of having the Emacs module API do that for you?

Well, the very existence of `ignore-errors' is an abomination, you can
hardly expect me to condone its automatic use. :-)  Suppressing errors
screws exactly the non-Emacsy developers it's supposed to help -- the
callback code is nearly impossible to debug without the Emacs
expertise that we're assuming the module developer *doesn't have*.

Also, the expense of an unnecessary condition-case in a tight loop is
not to be ignored, when the Lisp-level "no brain required" safety belt
for code that might signal but isn't performance-critical is so simple
and stylized.

But in most modules, we're just using library code to do a
calculation, and then we can pass the result (including signaling an
error status) back out to Lisp.  XEmacs (and even more so SXEmacs)
have been doing this a lot over the years.  The necessary code is
pretty boring, and I've never seen one that involves the nonlocal exit
issue.  The Lisp APIs that are most frequently used are hard to reduce
(DEFUN, DEFVAR).  GCPROs (S?XEmacs still uses them) are very rare, and
even those can generally be avoided by sticking strictly to the
marshalling/unmarshalling in C, and doing Lisp manipulations in Lisp.

The problem that Daniel is worried about is real, but I don't see a
good way of solving it in Emacs.

In any case, it doesn't matter to encouraging use of modules.  The
vast majority of modules simply won't have callbacks to deal with.
People who *want* to write a callback in Lisp and pass it to C are
going to be rare, and likely to be experienced Emacs developers, I
would think.  If not, they're surely multilingual.  They probably can
deal with it.