Re: [Gnu-arch-users] Extension language

[Tom Lord]

    > From: Joshua Haberman <address@hidden>

    > On Fri, 2003-10-17 at 08:53, Tom Lord wrote:
    > > 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.

    > I personally resist the CLI-as-programmatic-interface idea for two main
    > reasons:

    > 1. The vast majority of programs I have encountered that use external
    > programs through a CLI have been fragile and had not very useful
    > interfaces.  They are fragile because supplying input requires careful
    > treatment of the shell and quoting, 

Not at all.  Not a few popular languages seem to think that the
primary interface to subprocesses is `system(3)' which does exhibit
the problems you describe.

`system(3)' should only ever be used for only two reasons:  (1) you're
writing a quick hack and don't care much,  it's the most convenient
thing at hand;  (2) you are accepting sh(1) commands as input and want
to execute them in the exact manner of system(3).

Normally you should use subprocess mechanisms that don't involve a
separate shell at all and I'll point to two examples:

        SCSH process notation (the whole ball of wax in a neat little package):

        http://www.scsh.net/docu/html/man-Z-H-3.html#node_chap_2
        

        Emacs process functions (a handy subset of the available
        functionality):

        
http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_577.html#SEC580



    > and output requires careful parsing of flat text to create data
    > structures.  

That is fundamentally a feature because it allows output to be viewed
from multiple perspective, e.g., where `grep' sees lines, `tsort' and
`join' see fields and so forth.

I'm all for structured I/O of this or that sort, but the need to parse
something is not, in and of itself, a source of fragility.  (What
might sources of fragility are poorly designed or documented formats,
formats that change rapidly, and the absense of help from a compiler
that warns you when an interface has changed -- such problems have
reasonable solutions, though.)



    > Their interfaces are often not useful because they
    > are bound to revolving around the operations that the CLI
    > provides.  I don't know what kind of CLI programmatic interface
    > you have in mind, but it seems to me that it is difficult to
    > provide in a CLI the same granularity as a traditional
    > programming interface.

I think that the vague idea of "the same granularity as a traditional
programming interface" is not a helpful idea in this context.

    > 2. It reduces portability since it requires a shell 

It does not.

    > and finding the location of the target binary.  

It does not, in all instances, but even when it does: how does that
"reduce portability"?  Generally speaking, providing configuration
options that say where to look for a particular binary _increases_
portability.

    > Do you intend to increasingly depend on
    > a POSIX environment, such that the possibility of running on (say)
    > Windows without Cygwin becomes more remote?

Why not?   In the worst case, supposing a native windows port suddenly
became highly desirable, the system is small enough to reimplement
from scratch.

-t