Re: [Gnu-arch-users] ViewARCH-0.0.2

[Tom Lord]

    > From: Jonas Diemer <address@hidden>

    > As I understand, ViewARCH interfaces with tla, right?

    > Wouldn't it be cool if all of archs functionality was bundled in
    > functions of a library which tla and ViewARCH (and others) would link
    > against?

    > That way, the frontends would be fairly immune against changes in the
    > tla syntax. I think it also makes sense from Tom's "arch is
    > specification based, not implementation based" way.

    > I haven't looked at the tla sources to see how the status quo is...

Perhaps, or perhaps not.   There's three issues:  long-lived
processes, three-stream processes, and interface stability.

There's quite a leap in the tedious details of interface and
implementation complexity between a library routine designed to be
used in a short-lived process that can be safely exitted from the
library, and a library routine designed to be used in a longer-lived
process that expects the routine to always return except under the
most dire circumstances.

As a simple example: in a routine for short-lived programs, you can
often just print an error message and exit if given bogus parameters
-- in a routine for long-lived programs, you should extend the routine
to return an error code.   So that complicates the interface.

And if the set of routines in the library depend on one another, then
internally, in a library for short-lived programs you just call
functions and assume they either succeed or exit -- in a library for
long-lived programs you have to check returns for error conditions
and, if one occurs, clean-up state and propogate the error up the call
stack.

libarch is currently a library for short-lived programs.

On the other hand: libarch is also ruthlessly simple-minded about its
internal state, partly to make it easier to go back later and add
error-returns and return value checking.

So, yes, you could modify liblarch to be suitable for linking into a
long-lived program.   It's far from an intractable problem.



The next issue is the difference between library routines for a 
program that uses std{in,out,err} in the usual way, and routines for a
program that may not use those streams for ordinary I/O at all (such
as a GUI).   In the former, library routines can write directly to
stdout or stderr, for example.   In the latter, that data should be
handled differently.

liblarch is slightly closer to being a library for three-stream
programs.  Some of the routines produce results directly by printing
stuff, for example.

On the other hand: the I/O library that libarch uses to print stuff
has support for "virtual streams" which write to a memory buffer.  So
it wouldn't be too hard to find any places where descriptors 1 and 2
are hardwired in the library and provide an option to redirect them so
that callers can get that output back as a string (or even just direct
it to some other stream).


The final issue I wanted to mention is interface stability.
"Officially", the 1.1preX series is the one in which the CLI is
tweaked to maximize the happiness of users -- after which the goal is
to hold it stable.

There is no current plan to stabilize the interface to libarch.   

On the other hand, in practice, the interface to most of libarch has
been exceedingly stable so that (other than adding things like error
returns) it's not too far fetched to contemplate adding doc comments
and start considering it exported.

As Miles pointed out -- the one notably unstable part of the interface
to libarch are the functions that implement `main' for various
commands.  They take argc/argv of parameters and, obviously, the
syntax of the arguments passed that way changes as the CLI gets
cleaned up.

-t