From: William Paul Vrotney
Subject: Re: Shell syntax and Scheme (Reply to Chris Bitmead)
Date:
Message-ID: <vrotneyE8u5Gr.58w@netcom.com>
In article <··················@lambda.ai.mit.edu> Olin Shivers <·······@lambda.ai.mit.edu> writes:
>
> From: ·············@alcatel.com.au (Chris Bitmead uid(x22068))
> Subject: Re: Ousterhout and Tcl lost the plot with latest paper
> Date: 18 Apr 1997 10:24:54 +1000
>
> I've often thought that if I ever wrote a Scheme shell, I would
> provide an option to put in a line prefix and suffix to lines just to
> satisfy this point. You might do something like this...
>
> $ scheme
> > (write 'foobar)
> 'foobar
> > (set! prefix "(")
> (> set! suffix ")")
> (&)> write 'foobar
> 'foobar
>
> As you see, by setting the prefix and suffix variables a "(" and ")"
> would automatically be prepended and appended to each line you
> type. The prompt would change to "(&)" to remind you that this is in
> effect. If you wanted a shell like a Unix shell that runs other
> processes you might change it to "(run &)" which would automatically
> call the run procedure on anything you type in. This would allow you
> to type ls -l at the prompt and have it work.
>
> I would suggest that you'd be better off sticking with a classic
> shell-like syntax for the common, everyday issuing of commands, not
> simply punting the outer layer of parens. Globbing, for example, is
> an important interface between the filesytem and the command line arguments
> given to programs. This is built in to the syntax of typical interactive
> shells.
>
> If you wanted to do an interactive shell on top of Scheme, you would
> want to implement a lexer/parser to handle the shell syntax. You would
> also want to tweak the design of the shell syntax to allow escapes to
> Scheme for complex things. Having escapes to Scheme syntax and semantics
> would punt a lot of unnecessary things from your simple, interactive
> command language that are necessary for scripting, because you always
> have Scheme for them, such as conditionals and other control-flow operators.
>
Although I generally agree with Olin's suggestions about Chris's idea, I
think that Chris's idea nevertheless hints at a possibly more elegant
solution to the problem. In all due respect to Olin (and I did read one of
the earlier papers on the scheme shell), implementing a separate *fixed*
lexical/parser and tweaking it to accommodate escapes to Scheme (although in
itself a big step forward) sounds like yet another even more complex csh
to some people.
Consider that the only reason for the interactive shell version is for speed
of typing. And we will go one further by saying that it is for speed of
typing and ease of understanding for the particular user. This strongly
implies that the syntax of the interactive shell be completely customizable
to the user as in Emacs. Since scripts would always be in plain Scheme
syntax this would not present a problem for portable scripts. Although
there is even a way around this.
Based on this here is yet another suggestion:
1. There is an interactive shell mode.
2. In (1.) the interpreter works only slightly differently as follows:
Normally when a function variable is typed (not as a car) it returns the
function description. In interactive shell mode it still works this way
unless in the user's rc file or explicitly it is told to operate in the
"translation mode".
3. In the "translation mode" a function variable detected at top level would
trigger a translation of the subsequent text to a legal Scheme expression.
There is always a translation to a legal Scheme expression or else an error
message where the subsequent text does not translate. There is also a
function that shows the translation of any string.
4. (3.) is achieved by a set of translation rules that would have some
advertised but very simple default. In addition to the default the user
could fully redefine and customize part of all of the translation rules in
an rc rules file. When anything is typed in the interactive shell the
interpretation of the translation rules produce an expression which is then
evaluated. The rc rules file would not normally be read when interpreting
scripts.
5. Translation rules would normally apply to all functions. Specific
translation rules could be specified for particular functions or list of
functions.
6. A separate package of OS/file-system interface functions are defined at
the Scheme level to provide target translations. This would include things
such as pipes, redirection, history recall etc. Generally anything that can
be done in interactive mode can be done in normal Scheme mode.
This has the following advantages:
a. Interactive syntax is completely customizable by the user. (not important
but, conceivably even a "customized script" could even be portable if
accompanied by the translation rules).
b. Past the point of translation, everything is Scheme expressions, so the
semantics of the system is easy to understand.
c. The interactive syntax is extensible allowing experimentation.
d. The interactive syntax is explicit avoiding implicit syntax pitfalls such
as some of the ugliness built into the csh spec that can't be undone.
e. There is a clean division between ordinary Scheme and the OS/file-system
interface package. Also the shell system could be built on top of an
existing Scheme implementation.
--
William P. Vrotney - ·······@netcom.com