Re: Dynamic loading progress

[Stefan Monnier]

> Representing errors more conventionally is cheap.

AFAIK "representing errors more conventionally" means wrapping every
single function we pass to the module API.  That's definitely not cheap
in terms of performance.

> If there's even a small chance that I'm right about the safety and
> maintainability advantages of using purely local exits,

Representing errors as exceptions also has advantages.

> why not err on the side of caution? AFAICS, there's no advantage to
> using non-local exits and plenty of risks.

There are very many advantages, on the contrary.

Also, I expect most module authors will be familiar with Emacs, and
having to learn a different style will be an extra hindrance.

>> But the issue only comes up once these non-Emacs libraries call back to
>> Emacs functions (i.e. step 5 in my example).  So only those calls need
>> to be protected somehow from non-local exits.
> Calls back to Emacs functions will be fairly common, because modules use
> these functions to manipulate Emacs data on behalf of their own callers.
> Any of these functions can quit. What you're imagining will be a rare
> case will in fact be common.

You're not talking about the "step 5" case.  You're talking about the
Emacs-specific module code calling Emacs functions.  Indeed, this will be
very common.  But to write this code, you will have to know a fair bit
about Emacs internals, anyway.  It will not look like your "typical C++
code".

> I also don't think it's correct that the Emacs-specific module code will
> work properly in the presence of modules. You're supposing too much
> patience and knowledge on the part of third-party module authors who'll
> want to provide bindings not only for Emacs, but for other systems as well.

I don't forsee droves of coders who no nothing about Emacs internals and
who start writing third party modules.

In any case, I think it would be easy to layer the kind of API you
imagine on top of the kind of API I imagine, whereas the reverse seems
to be much more difficult and/or much less efficient.

So I'd rather we go with a straightforward lean API for a start.
And we can develop an alternative API on top afterwards (it might even
be possible to implement this alt-API as a module).

>> Of course it is.  We already do that in Emacs's core with things like
>> safe_call.
> safe_call blindly suppresses errors.

You're nitpicking.  Of course we'd use something slighly different which
stores the error somewhere.  Th point remains that it's easy to provide
such a wrapper.

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

[ Is there a verb missing, maybe, I can't quite parse this, sorry.  ]


        Stefan