Re: Oddities with dynamic modules

[Philipp Stephani]

Am Do., 11. Okt. 2018 um 20:13 Uhr schrieb Eli Zaretskii <address@hidden>:
>
> Having written the documentation of the module API, I couldn't help
> but notice a few oddities about its repertory.  I list below the
> issues that caused me to raise a brow, for the record:
>
>  . Why do we have functions to access vectors, but not functions to
>    access lists?  I always thought lists were more important for Emacs
>    than vectors.  If we are asking users to use 'intern' to access
>    'car' and 'cdr', why not 'aref' and 'aset'?
>
>  . Why aren't there API functions to _create_ lists and vectors?

I guess these are mostly historical. These were introduced in
https://github.com/aaptel/emacs-dynamic-module/commit/016e8b6ffdfb861806957bb84c419a3d65caedb7,
but I don't remember the background.

>
>  . Using 'funcall' is unnecessarily cumbersome, because the function
>    to be called is passed as an 'emacs_value'.  Why don't we have a
>    variant that just accepts a name of a Lisp-callable function as a C
>    string?

Convenience is not a design goal of the module API. The primary design
goals are robustness, stability, simplicity, and minimalism.

>
>  . Why does 'intern' only handle pure ASCII symbol names?  It's not
>    like supporting non-ASCII names is hard.

Unfortunately it is, due to Emacs underspecifying encoding. If we can
manage to write an 'intern' function that accepts UTF-8 strings and
only UTF-8 strings, I'm all for it.

>
>  . I could understand why equality predicates are not provided in the
>    API, but I don't understand why we do provide 'eq' there.  Is it
>    that much more important than the other predicates?

Yes, it represents a fundamental property of objects.

>
> IOW, if the API was supposed to be minimal, it looks like it isn't;
> and if it wasn't supposed to be minimal, then some important/popular
> functions are strangely missing, for reasons I couldn't wrap my head
> around.

It is *mostly* minimal. A *completely* minimal API would not even have
integer and floating-point conversion functions, as those can be
written using the string functions. But that would be far less simple
and robust.
"eq" and "is_not_nil" are special in that they implement access to
fundamental object properties and can't fail, so they are fundamental
enough to deserve an entry in the module table.

The best source to answer the "why" questions is still the original
design document:
https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00960.html