Oddities with dynamic modules

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Oddities with dynamic modules

Eli Zaretskii
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?

 . 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?

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

 . 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?

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.

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Oddities with dynamic modules

Kaushal Modi
On Thu, Oct 11, 2018 at 2:14 PM Eli Zaretskii <[hidden email]> wrote:
>
> Having written the documentation of the module API,

Thanks for writing up all that documentation!
https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26&id=ce8b4584a3c69e5c4abad8a0a9c3781ce8c0c1f8

I am not in the capacity to comment on most of your questions as I am
using the Modules feature to get around my lack of C knowledge :)

>  . Why aren't there API functions to _create_ lists and vectors?
>
>  . 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?

+1

I needed to create some sugar syntax in Nim (which compiles to C) to
get around that limitation:

proc MakeList*(env: ptr emacs_env; listArray: openArray[emacs_value]):
emacs_value =
## Return an Emacs-Lisp ``list``.
Funcall(env, "list", listArray)


proc MakeCons*(env: ptr emacs_env; consCar, consCdr: emacs_value): emacs_value =
## Return an Emacs-Lisp ``cons``.
Funcall(env, "cons", [consCar, consCdr])

It would be nice to have API for list (and cons).

>  . Why does 'intern' only handle pure ASCII symbol names?  It's not
>    like supporting non-ASCII names is hard.
>
>  . 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?

I had the same question too. I find equal more useful than eq.

Reply | Threaded
Open this post in threaded view
|

Re: Oddities with dynamic modules

Philipp Stephani
In reply to this post by Eli Zaretskii
Am Do., 11. Okt. 2018 um 20:13 Uhr schrieb Eli Zaretskii <[hidden email]>:

>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Oddities with dynamic modules

Eli Zaretskii
> From: Philipp Stephani <[hidden email]>
> Date: Sun, 10 Feb 2019 21:23:18 +0100
> Cc: Emacs developers <[hidden email]>
>
> >  . 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.

I thought simplicity and convenience of use tramps simplicity of the
implementation, so it is strange to read arguments to the contrary.
IME, inconvenient interfaces are the main reason for them being
unstable, but that's me.

> >  . 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.

What are the problems you have in mind?  After all, this is already
possible by means of 2 more function calls, as the example in the
manual shows.  Are there any problems to do the same under the hood,
instead of requiring users to do that explicitly in their module code?

> >  . 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.

How is that relevant?  Equality predicates are used very frequently
when dealing with Lisp objects; 'eq' is not different from others in
that respect.

> > 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.

I cannot follow this reasoning, sorry.  It sounds like you are saying
that the decision what to implement and what not justifies itself
because it's there.  All I can say is that as someone who wrote a
couple of lines of code in Emacs, the stuff that is in the API and the
omissions look quite arbitrary to me.

> 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

Which part(s) of that long document answer these questions, please?

Reply | Threaded
Open this post in threaded view
|

Re: Oddities with dynamic modules

Yuri Khan
On Mon, Feb 11, 2019 at 10:46 PM Eli Zaretskii <[hidden email]> wrote:

> > Convenience is not a design goal of the module API. The primary design
> > goals are robustness, stability, simplicity, and minimalism.
>
> I thought simplicity and convenience of use tramps simplicity of the
> implementation, so it is strange to read arguments to the contrary.
> IME, inconvenient interfaces are the main reason for them being
> unstable, but that's me.

A good middle ground is a minimalistic (but sufficient) API at the
host side, plus idiomatic convenience wrapper libraries for each
client language. (The latter need not be maintained by the host API
maintainer.)