SL Baur <steve(a)beopen.com> writes:
> > Thus a good first step for creating an API would be to *keep* the
> > distinction of C/Lisp as the line between the implementation and the
> > interface. For instance, we can say that the modules are allowed to:
>
> > * Define Lisp functions, symbols, and variables using DEFUN,
> > defsymbol, and friends;
>
> > * Call existing Lisp functions using call* and Ffuncall(). For
> > instance, call2 (Qfoo, make_int (1), Qbar);
>
> > * Call a small set of C functions directly -- stuff like Fcons() and
> > Fget(). Given that all the needed functionality is available under
> > the previous item, the initial number of functions in this set could
> > be kept minimal.
>
> > Comments?
>
> You left out
>
> * define new lrecord types
Right. That goes under "friends" above.
> * acess to a subset of standard symbols (for basic coding systems,
> etc.)
I took that for granted. For my second point to work, you have to get
at any symbol whatsoever. Like:
static Lisp_Object Qfoo = intern ("foo");
at the time the module is initialized.
> Also, is macro expansion an issue?
I don't know. It might be important for binary compatibility between
releases. But binary compatibility is very hard. We'll probably want
to offer only source compatibility for starters.
> Two other library interfacing issues I ran across doing the Postgres
> interface are:
> May I respectfully request that `define-error' be moved into C?
I thought we had deferror(), or something like that?
> May I respectfully request that the functionality of XtAppAddInput
> be added to the XEmacs event loop?
I think Lisp code should never have to deal with "file descriptors".
There should be a standard way to hook into the event loop from C,
though.
I remember that William Perry used something like that to get the GPM
support right. Bill, what do you think about this?
> The Postgres interface code needs this to be able to deal with the
> asynchronous interface adequately. Right now, hitting a blocking
> operation that never returns kills the editor and that is
> unacceptable.
For one, C-g should always work. Asynchronous operations are a pain
in Emacs, but they're also a must. I don't know enough about the
internals to understand the issues involved.
> Under Unix, we use select loops, either via Xt, or via a home-brewed
> version when running tty-only. Does a similar functionality exist
> under MS-Windows?
I don't think so. This kind of thing is much harder under Windows.
Remember Jonathan Harris' talk in Tsukuba last year? <shudder>