🚀 go-pugleaf

> rh@smds.UUCP (Richard Harter)
> The power of UNIX shell programming
> rests not in the shell language itself, but in the collection of tool
> programs that are standardly available, e.g. sed, awk, find, uniq, sort,
> and their interconnection with pipes and redirection.  [..but..]
> the execution of the resulting scripts is slow because each tool is
> a separate process, [...]

A thought that occurs to me is that the rapid adoption of perl in the
Unix community is a back-door defection to a philosophy that Lisp folks
have been preaching for years.  In perl, one is partly abandoning the
the notion of small, stand-alone tools that do one thing well, and
instead adopting the monolithic everything-in-one-language approach that
Lisp has always had.  You know.  "Swiss army chainsaw."  Perl simply
makes this palatable to the Unix community by leaving out some of the
parenthesis and including a baroque syntax and idiosyncratic semantics.  :-)

> The main point I would like to make is that it is not such a simple thing
> to design and implement a language, particularly one which is to have
> strong string manipulation capabilities.

Having had recent experience in doing just that (for the usual misguided
reasons), I mildly disagree.  By compromising runtime speed somewhat,
one can put together a complete interpreted string-manipulation language
for well under 2000 lines of C code and a month or two of elapsed time. 
This doesn't include design time.  Double or treble or more that effort
if you then need to squeeze speed out of the thing.  Does this match
other folks' estimates/experience?

As an aside, I also find it interesting that "everybody" seems to have
implemented or be implementing a tiny language or two, even if they
later repent.  I don't know if that's good, bad, or indifferent, 
but it seems to be so. 

> Message-ID: <552@smds.UUCP>
> However my point was really that it is not so simple to develop a general
> language that is a signifigant improvement on what is already available.

Ah.  Now *this* formulation seems more apt.  "Significant improvement on
what is already available" is the key.  Part of the problem is, just
exactly what's "significant" is a difficult question, and easy to be
self-deceptive about.  Wrangling with myself over exactly this issue is
what led me down the slippery slope of interpreter implementation.

Somebody who's name I forget just now, talking about TCP/IP and ISO,
coined an apt phrase in this regard.  "Just because your local tire shop
doesn't have four-ply radials in stock is no reason to go out and
reinvent the travois."

As I said, I myself have a fine travois which I use daily.  I don't
regret inventing it, and I learned a lot from it, and it is a fine and
dandy tool... but my original justification for writing it was, in
retrospect, insufficient.


Finally, I note that I'm familiar with at least one alternative to the
"brutal stripping" of syntax to allow the "outer interpreter" (eg: the
shell) to smoothly encapsulate several "inner interpreters" (eg:
commands with mini-languages in their arguments, like expr, grep, and so
on and on).  It is, however, somewhat trickier. 

Instead of giving symbols no interpretation at all, you can give them
*lexical* significance, but no *semantic* significance.  You can get
away with this because the lexical significance of characters is pretty
standard across languages.  For example, () always match, and so on. 
One also has to have a regular and predictable quote convention to deal
with the few leftover conflicts, sigh.  But one almost always has to
have some moral equavilent of this, even in "brutally stripped"
syntaxes. 

What this buys you is the ability to give multiple and more natural
semantic interpretation of characters.  Or to put it another way, the
semantics associated with the characters is determined by context, while
at the same time the shell isn't prevented from giving meaning to
characters so strictly.  This is especially important in a multi-lingual
debugger. 
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw