Re: Dynamic loading progress

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

Daniel Colascione writes:
 > On 09/13/2015 08:43 PM, Stephen J. Turnbull wrote:
 > > Daniel Colascione writes:
 > >  > On 09/13/2015 01:31 PM, Stefan Monnier wrote:
 > > 
 > >  > >> It's not possible to skip frames in module code using longjmp, so
 > >  > > 
 > >  > > Why not?
 > >  > 
 > >  > Because most C code isn't expecting to be unwound. Forcing non-local
 > >  > flow control on module code is completely unacceptable.
 > > 
 > > "Completely unacceptable" is nonsense.  Module code needs to be
 > > written the same way any other Emacs code is written, using various
 > > unwind-protect constructs.
 > 
 > Why? There is no positive reason to make Emacs module code resemble
 > Emacs core code.

Er, because it *is* Emacs code?  If a function in a module simply
wraps a library call, then you need to use that library's facilities
to handle problems.  But if it manipulates any Emacs data using Emacs
APIs, you'll use Emacs facilities to handle all that ugly stuff like
GC and Fsignal.

 > In fact, there's a strong reason to make Emacs module code more
 > conventional, because it'll improve the accessibility of the API,
 > which in turn will increase the quantity and quality of Emacs
 > modules.

I think that's wishful thinking.  In my experience with the XEmacs
module code, what basically happens most of the time is that you write
some Lisp to beat the data into the right structure, then you write a
little bit of C to marshal Lisp primitive types into the underlying
library's format, then you call the library API, and marshal the
return into Lisp data types.  Often it's more convenient to call the
Lisp APIs from C than to return to Lisp and do it there, but it's
equivalent.  Sure, there's a lot of boring boilerplate, but it ain't
rocket science by that very token.

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, or just wrap the whole thing in a condition-case (such as
ignore-errors) before passing it to the library.

 > The Emacs core code has a lot of baggage. It's not practical to
 > clean it up today, but the module system is a greenfield
 > project. There is no reason to burden it the same way.

AFAICS, no, it's not a greenfield project.  It's a second story on the
same foundations.  You're welcome to prove otherwise, but I don't have
a clue how you propose to do it (without disallowing callbacks into
Lisp entirely, and I don't see how you can enforce that without some
very pervasive nannying code).

 > Can you name an extension system for any other program that
 > longjmps out of its public API functions?

No, not with any confidence.  XEmacs is the only program whose
internal implementation of nonlocal exit I know well.  But I would
guess that if the language implements nonlocal exits, then any
callback that can be an arbitrary function in the language can
longjmp.