Re: [Gnu-arch-users] Extension language

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    > I want XEmacs to have Lisp bindings to arch internal functions
    > so that I don't have to change my parser every time somebody
    > fixes a typo or lack of clarity in a message or makes things
    > more terse, and change my wrapper function when somebody gets
    > rid of a tla option or ....

I'm really not so sure that's what you really want.

_Even if_ libarch is thoroughly turned into a "safe for long lived
process" library (and that change is just simple, mechanical,
correctness preserving tranforms) -- even if that were to happen, I
still don't think you'll want it linked into XEmacs.

For example, would you also want the long-running commands to be made
interrupt safe so that `commit' doesn't turn off ^G?   Aren't you
concerned about the size of the processes data space consumption?
What about bugs since every new line of C code in an Emacs is a new
opportunity to core dump?

I think you want a stable CLI and, since you don't want to be stuck
with 1.0.6, I guess you have to wait a _little_ while longer.   I
don't think that your code should be written in a way that makes it so
senative to changes in output format -- but also the output format
should be designed to help that (by not having much that could
conceivably change).   Really, the current _instability_ in the CLI is
a huge (though rapidly disappearing) opportunity for you.

But you're also suggesting a firm separation between the interactive
CLI and the programmatic interface.  That's a fine idea and it remains
a fine idea even if we say that the programmatic interface is itself a
CLI.  There's nothing wrong with adding new commands (presumably
hidden by default) whose primary purpose is to provide a programmatic
interface.


-t