Re: Dynamic loading progress

[Stephen Leake]

"Stephen J. Turnbull" <address@hidden> writes:

> 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?  

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.

One reason Emacs succeeds is because lisp is so forgiving; module
developers will expect the Emacs module API to be similarly forgiving. I
don't think we need to accept that as a hard requirement, but anything
we can do towards that goal that has reasonable performance penalties
could be a win. 

>  > 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.

I see that as "conventional code"; you certainly didn't mention
callbacks and longjmp here.

> 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?

-- 
-- Stephe