Re: Language-neutral interface specifications (research)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Jul 12, 2022 at 09:57:20AM -0400, Mouse wrote:
 > >     a. Define the source-level API in a way that is detached from the
 > >        C language.
 > 
 > This can be done, but only by attaching it to some other language
 > instead.  It doesn't even make sense to talk about an API without it
 > being an API for some specific language; an API is an Application
 > _Programming_ Interface, and you can't program without programming in
 > some language.

Eh. That's true, but only in a degenerate sense. Functions and data
types exist beyond their source language; that's why binary
compatibility is a thing and why foreign-function interfaces are a
thing. It makes sense to talk about functions and data types outside
of the context of any specific programming language; obviously
whatever you concoct to talk about them in is also a language, but
only in a degenerate sense.

What's the language of /usr/include/rpcsvc/yp.x? Not C. I'm sure it's
possible to generate Ada code from it, and there's a reasonable chance
someone might even even written that tool.

 > >     c. Define data flow better than C allows: The struct stat*
 > >        argument to stat() is only meant to move data out of the
 > >        function.  The pathname pointer isn't captured by the function
 > >        call.
 > 
 > Doesn't the restrict qualifier get you at least part of this?

Only a little. It tells you that the pathname doesn't(*) overlap the
stat buffer in memory.

Data direction isn't something you can express in C (though most IDLs
support it) and capture of references isn't at all.


(*) The definition of restrict in C99 is nerfed such that it actually
has extremely limited utility. I forget the details though, and I
don't know if it's been fixed in C11 or C17.

 > It sounds to me as though you want an ABI description language, not an
 > API description language.  A C - or C++, or any other language except
 > Ada - API is of minimal value for you, except (a) to the extent that an
 > ABI can be inferred from it or (b) to the extent that you are
 > generating code in that "other language".

What one wants is a description that can be used to provide compatible
API declarations for many languages, such that after passing through
their respective compilers the resulting ABIs are the same or at least
interoperate correctly.

 > Indeed, one could argue that an ABI is, essentially, an API for the
 > machine-code level.

Except for machine-level interfaces (e.g. calling convention specs),
which we also refer to as ABIs, ABIs are what you get when you run
APIs through a compiler.

Technically speaking though they're still not user-facing. If you
wanted to code to one of these interfaces at the machine level you'd
want assembly-level API definitions. That's what genassym does.

-- 
David A. Holland
dholland%netbsd.org@localhost