Re: Dynamic loading progress

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden
> Date: Sun, 15 Feb 2015 17:03:21 +0900
> 
>  > I simply don't believe this goal to be practically achievable, if
>  > there are no limitations on the interface.
> 
> The limitation is obvious: in principle, all Lisp objects are accessed
> through Lisp

Not sure what that means in practice.  What would be the definition of
a Lisp_Object visible to a module?  Will it be what we have on lisp.h,
or some opaque object?

> with the exception of numbers.

Why the exception?  What if the internal representation of a number
changes?  (It already did, a few weeks ago.)

> Even for strings and buffers you can call Lisp "coding system"
> functions.  You may need to add an "internal char[] buffer" type to
> serve as source/sink (I'm sure you already have one for stream I/O,
> but it probably doesn't have a formal or stable definition).

I don't follow: why coding-systems are relevant here?  Perhaps you
have XEmacs implementation in mind.

>  > I also am not sure that people would accept forward incompatibility
>  > easily: consider the number of people who use bleeding-edge Org, Gnus,
>  > etc. with the last official release of Emacs.  Why would they agree to
>  > lose that when part of a module is in C?
> 
> For the same reasons they do when a package decides to use some new
> feature of Lisp that is forward incompatible.

Using Lisp objects is not a new feature, so I don't think this analogy
will hold water.

> If Emacs is unwilling to be disciplined, package maintainers won't
> use C modules, or will call through Lisp and otherwise treat
> external Lisp objects as opaque.

I think they will rather apply pressure to avoid changes that break
binary compatibility, which in the long run will limit development.
Not sure if we want that; something to discuss, I guess.

>  > And what about accessing Lisp objects?  Most of them are accessed
>  > through C macros, whose definitions change as the internals change.
>  > What can you do with those to preserve compatibility across Emacs
>  > versions?
> 
> Prohibit such change, or add accessor functions with a stable ABI
> encapsulating the accessor macros to a table for use by externally
> compiled modules loaded at runtime.

That's what I tried to do in my suggestion for the API, but I don't
hold my breath to see it accepted.  Stephen Leake already said he
didn't like it; I have no reason to believe I will hear anything
different from others.  The way the current modules on the branch are
written are a good sign of what will follow, I think.

> If you expect you must change some ABI in the future and can't/won't
> use the method table approach, tell module writers to access them
> *through* Lisp and live with funcall overhead.

How can funcall help you access Lisp objects and convert their values
to something that C can grok?  Sooner or later, you will have to
access the internals of the objects.

So the funcall issue is irrelevant to accessing Lisp objects.

>  > More to the point: I simply don't see any reason for calling Lisp from
>  > C.  If a module needs to do something in Lisp, let it do it in Lisp
>  > directly, as every external package for Emacs does.  C code should
>  > be reserved for providing additional primitives that core Emacs
>  > lacks, and that's all.  At least that should be the starting point,
>  > IMO.
> 
> But you're not the one who wants this feature.  The people who do want
> this feature, in both XEmacs (which has more than a decade of
> experience with ELLs) and now in Emacs, have accessed, or think they
> need to access, Lisp objects from their C code.

Yes, I understand that.  And because of that I don't believe the
"stable API" paradigm will be accepted.  I think people will want to
write modules with the same freedom and flexibility we write core
code.  Which means the "tightly-coupled" paradigm.