>Paul Wilson wrote:
>> (John Ellis?) did a Lisp shell several years ago, where any
>> unbound function name was assumed to be an indication that
>> the programmer meant to call a UNIX program. [...]
>I thought (I'm about 800 miles from my Scsh docs ...) Olin explicitly
>wrote about this in his document (in the Tao section?). I agree with
>Olin on this front. One of the reasons I would even be interested in
>this command system is to integrate the two environments cleanly. To
>then make commands dependent on the environment strikes me as a stride
>in the wrong direction.
You can't integrate the two systems cleanly. How many unix programs know
what to do with scheme objects?
Most shells do not have any data structures other than strings.
Even if they have functions, there is very little difference in semantics
between running a locally-defined function, an external shell script, or a
One shell with slightly more complicated data structures, es, has--among
other things---first class procedures and lexical scope. You can create
closures and even pass them to es subshells via the environment, but there
are serious problems:
1) multiple references to the same closure become separate
instances in the subshell because of the way they are encoded in
2) State is passed in the unix "environment" strings, which are
severely limited in size; if the environment is too large, you
will get an error from the exec system call. But other than the
3 standard IO streams each program is started with (which
already have predefined uses), there is no univeral mechanism in
unix for propagating information from one program to another.
You are screwed.
3) Es strived to integrate its own environment with the external
world of commands, so some sacrifices had to be made in the data
structures it implements. Since its "lists" are used so often
to construct command-line parameters and the syntax could not be
made too cumbersome, es does not support nested lists; they are
always flattened. (You can get around this by embedding
sublists in closures, but then they are more cumbersome to
identify and use, since there is no real typing.)
4) Structures which ordinarily can be modified by side effect,
e.g. lists, cannot be changed by another process.
With scheme's far richer set of objects (continuations, port objects, etc)
the problem of integrating them in the manner you propose would be far worse.
Other than a handful of shells intended primarily for running commands and
only later adopted for scripting (vs languages intended for scripting in
the first place), I doubt you will find any language that has the behavior
that Paul Wilson proposes. Even in perl, there is explicit syntax for
running other programs.
I think Olin made the right choice.