Re: Oddities with dynamic modules

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Thu, 21 Mar 2019 21:12:05 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > How is that relevant?  Equality predicates are used very frequently
> > when dealing with Lisp objects; 'eq' is not different from others in
> > that respect.
> 
> I don't recollect the reasoning, but Daniel stated that "eq" is
> strictly necessary, so you might want to ask him.
> [...]
> > > 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.
> 
> Please see Daniel's original reasoning for the design.

I asked the questions after reading that, so please believe me that I
didn't find answers to my questions there.

> Mostly the first sentence "We want an ABI powerful enough to let C
> modules interact with Emacs, but decoupled enough to let the Emacs
> core evolve independently."

That means a judgment call, and I was questioning the judgment.
Saying that someone made a call doesn't explain why the decision was
what it was.