Re: Dynamic loading progress

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Stefan Monnier <address@hidden>,
>     address@hidden,
>     address@hidden
> Date: Sun, 15 Feb 2015 18:21:54 +0900
> 
>  >  . Some definition of Lisp_Object
>  > 
>  >    This already presents at least 2 problems.  The first is 32- vs
>  >    64-bit issues.  We need some way of checking that a 32-bit module
>  >    isn't loaded by a 64-bit Emacs, and vice versa.
>  > 
>  >    The other problem is more serious: Emacs can be built with or
>  >    without --check-lisp-object-type, and with or without --wide-int;
>  >    how will the module know which implementation to use?
> 
> XEmacs builds a separate compiler driver ellcc that knows how to build
> modules of the same configuration.

That won't support binary distributions of modules, would it?

>  >    Perhaps the solution is to make Lisp_Object an opaque data type for
>  >    the modules, and not use the definition we have on lisp.h.
> 
> I don't know how you identify type of objects, but since you only have
> a couple of tag bits left, I have to assume you use a header word of
> some kind.  In XEmacs the header word is a pointer to a table of
> functions that define the common functionality of Lisp objects used by
> the interpreter and the virtual machines.  Whether a method table
> pointer or an enum, that header word is pretty much the only thing
> that's going to be common to all types.  Seems to me that's pretty
> close to opaque already.

Making a Lisp_Object opaque, one way or the other, is easy.  Getting
people to accept that it will be opaque is harder.  I posted my
suggestion to try to convince that this is the way to go, but I'm not
holding my breath, frankly.

>  >  . Functions to access values of Lisp objects.
> 
> Not values, attributes.

I don't think the difference matters for the purposes of this
discussion.  The intent is to allow extracting a C int from Emacs
integer, a C double from a Lisp float, a C char array from a Lisp
string, a pointer to buffer text for buffers, etc.

> You don't want to just unbox the Lisp object and give modules access
> to internals.  Rather, each object type should export a specific API
> in the form of accessors and mutators for its Lisp-visible
> attributes.

I don't think modules will settle for using only the Lisp attributes,
they would like access to C attributes as well.

>  > The above means that most of the C source files under modules/ should
>  > be thoroughly rewritten.
> 
> Sounds like a good idea to me.  Wouldn't hurt if you rewrote most of
> the C source under src/ that way too. ;-)

I'm not holding my breath.