Re: Dynamic loading progress

[Stephen J. Turnbull]

Daniel Colascione writes:

 > Calls back to Emacs functions will be fairly common, because
 > modules use these functions to manipulate Emacs data on behalf of
 > their own callers.

Real examples, please.  S?XEmacs has two decades of experience with
wrapping random libraries, Emacs has some too, and there just aren't
any that I can think of offhand.  I see no reason why modules in Emacs
will change that pattern; S?XEmacs has a 1.5 decades of experience
with require'able modules, and it hasn't changed there.

 > Who will be common, because the entire point of writing modules is
 > to work with the _non_-Emacs world. I can imagine one module that
 > has both non-trivial calls back into Emacs and quite a bit of
 > internal state in suitable for management with Emacs
 > primitives. It's called Python.

You have a serious licensing problem, I think, which is one of the
important reasons why we haven't seen very much in the way of complex
integration in the past.  But be that as it may....

You're kidding, right?  I can't imagine that somebody with the skills
in both Python and Emacs and the energy and time needed to write the
kind of deep integration you're talking about would be deterred by the
need to adapt a couple score lines of "suggested code" to their
preferred conception of error handling.

Of course it will be hard to write the boilerplate the first time, but
by the same token the first try will undoubtedly suck.  So the
implementation will *change* to fix the suckiness.  If the boilerplate
is embedded in the module API it will likely force the modules to
update to work with the new rules.  I think a module that seems to be
working well is very unlikely to be pleased by such churn.

So, you could be right in the long run, but I think it's the better
part of valor to not restrict modules in that way now.  Instead, put
the responsibility for error handling the callback itself first.
Modules that want to can provide their own child-proof wrappers.
After experience incorporate the best (plural, if appropriate) of
those wrappers in Emacs itself, either embedded in the module API or
as an optional standard wrapper.

 > safe_call blindly suppresses errors. Errors from module-invoked
 > functions to propagate normally from the perspective of surrounding
 > Lisp code.

Show us the code to "propagate errors normally to surrounding Lisp
code".  XEmacs has its own safe_call-type functions that do somewhat
better than merely suppressing all errors, but they're heavy and hard
to use correctly -- and there we know at least that the calling side
of the call is XEmacs (the other side is typically low-level I/O code
that uses Lisp to format output or parse input).  But for modules,
since callbacks can be anything and the callback will be separated
from the "surrounding Lisp code" by arbitrary amounts of non-Lisp code
doing unknown things, I doubt you can do "normal".  But let's see how
close you can get.