Re: Another vote for a built-in read function

[Scott Schwartz <schwartz@groucho.cse.psu.edu>]

| I suspect that there are a lot of us without easy access to that news
| group.  (or just too busy to look)  Could you summarize for us?  Or at
| least indicate which way the discussion was leaning?

Sure. There are two basic points, which I'll try to explain as best I
can given that I've only read about multics, but used some of its
descendants (prime's primos and apollo's domain).

One is that multics has pervasive dynamic linking.  The fundamental unit
of sharing is the procedure.  Any procedure in any file in your search
path can be called at any time.  Your environment is one big process,
you don't fork to run programs, you just call their entry points as
subroutines.

The second is that there is a convention of using "active functions" in
the command language.  That means that commands see of they are being
called interactively, in which case they print their output, or being
called as subroutines, in which case they pass their output back by
returning a pointer to a buffer.

The upshot is that in multics, if you have a command to read a line
named >bin>line, and >bin is in your search path, you can call it from
your program by calling a routine named line_ and it will be exactly as
if it were a "builtin", because it is.

There was an interesting discussion between Peter da Silva and Olin
Sibert over the find command.  Olin pointed out that ``find ... -exec
...'' is more multics-like than unix-like, but unix has to use xargs as
yet another performance hack, with concomitant correctness problems. 

I can post Olin's whole article or forward it to anyone who's
interested.  

(As an aside, the word "glob" in unix comes from a command in multics
named "global", making it more like globbing in zsh.)

In my view, and the reason I brought this up at all, a real problem in
Unix, and in posix like systems, is that the unit of sharing is wrong.
The best you can do is write text down pipes to forked processes.
Sometimes that is fine, but very often it is not enough, or just plain
wrong, and the rc community has encountered a perfect example of this.
Similar issues came up in comp.lang.tcl a while back.  In a unix
setting, having a language primative for doing dynamic loading is about
the best compromise you can achieve.

And now for a diatribe; please skip to the end if I'm annoying you. :-)
This wrongness is very bad because it distorts programmers ideas of what
should be reusable; in the end, nothing is.  Consider, why does ftp have
its own subroutine for doing globbing?  I mean, if you can't just call
the globbing routine in the shell, why can't you at least use the same
damn library routine?  There isn't any!  You don't need system sources
to get it right, just a libsh.a with a sensible api!  (The latter is
complicated by the fact that we insist on using a '70s vintage
programming language that has basically no support for code reuse, and
still manages to be an improvement over its "successor".)