shell compiler

[Conrad Kimball]

In article <1991Apr16.032713.21502 at convex.com>, tchrist at convex.COM (Tom Christiansen) writes:
|> As I continually point out, an sh compiler will help you very little.  You
|> need to decompose and recompose your program to minimize execs and
|> redundant data passes and then recast it in a more suitable language, like
|> [gn]awk (maybe), perl, or C (as a last resort).  Merely compiling the
|> conditionals buys you nearly nothing.

You are right that the primary goal is to minimize execs and such.  BUT,
I believe that a reasonable shell compiler would convert many of the
"shell language" components that are now execs into C function calls that
are semantically equivalent.  For example I have some elaborate scripts
that use lots of "expr" and "tr" commands.  If these were compiled into C
the result would run many, many times faster.

Sure, I could recode the script into another language, but why?  Scripts
are an easy-to-use coding language for incremenntally developing small to
medium size programs.

I liken the issue to that of compiling ordinary languages.  I've got a
program written in the XYZ language that currently executes correctly
but slowly in an interpreted fashion.  I would like a compiler for the
XYZ language that produces highly optimized machine-level object code.
To do this the compiler quite often (especially for vector computers)
recognizes specific constructs in the XYZ language and maps them into
special machine language sequences or calls to special internal functions
that are optimized for speed.  Now, in this case the special constructs
to be recognized are simply some of the commonly used Unix filters.  Note
that in the DOS world there are several "batch file" compilers that
essentially do just this.


--
Conrad Kimball 		 Boeing Computer Services     (206) 865-6410   
Email: cek at wsc-sun.boeing.com or cek%wsc-sun at atc.boeing.com
UUCP:  uw-beaver!bcsaic!wsc-sun!cek