In article <qijent67nl3.fsf_-_@lambda.ai.mit.edu>,
Olin Shivers <shivers@ai.mit.edu> wrote:
>
>If we are going for an interactive command language, then anything goes --
>it doesn't have to be readable, just writable. So punt the parens as well,
>and do a simple, real shell syntax. If you want to do anything complex,
>escape to Scheme.
I think you may want to be very careful here. It's a good idea to
have a grammar schema that can support lexically-scoped macros gracefully,
even for a simple terse-mode interactive shell, and even if you expect
people to use real Scheme for most of the hard stuff. I don't think
you want to adopt an "anything goes" attitude toward a terse grammar.
At first glance it may seem that having a split between terse mode (for
simple stuff only) and real Scheme (for anything difficult) would mean
that there are no real constrains on the design of terse mode. I don't
think that's the case---it may be *more* important to have powerfully
extensible syntax for terse mode.
>I designed a shell syntax along these lines maybe two years ago, but
>I never implemented it, and I've have to spend some time looking at
>my notes to figure out the details. As I recall, one of the Scheme escapes
>was $. So $foo gave you shell variables just like other shells, but you
>could also do things like $(string-append x y).
>
>My syntax was like rc's and es's in that it had a real, parsable grammar,
>and a clear read/parse/evaluate split, unlike the gruesome mess you have
>with sh and csh (csh has *seven* different expansion/evaluation stages!).
I don't think you want to assume that the grammar should be processable
with traditional read/parse/eval phases. A good infix syntax that supports
powerful macros may make this very difficult or impossible.
In the *short* term, it may be okay to *implement* a subset of the Right
Thing grammar using this straightforward approach. E.g., if you don't
allow macros in terse mode, you can have a fixed grammar that's doable
with read/parse/eval.
In the medium term, though I think you want to have macros in terse
mode, if only because it will make development of the system easier. It'll
be easier to define new handy syntax without rewriting the parser.
Eventually, you want other developers to be able to do this as well.
An example from your paper may be enlightening here---suppose you want to
implement an equivalent of make in scsh.
Limited syntactic extensibility generally results in people hand-coding
their own lame little parsers for their own poorly-though-out grammars,
and make is a stunning example of this.
If people hand-code their own parsers for their own little languages,
it also tends to make code integration harder. In a make-like tool,
you'd like to be able to declaratively specify a lot of stuff like the
usual dependencies, but you'd also like to be able to do some things
procedurally.
(Taking the "shell programming IS real programming" idea further, just
about any app is often best viewed as a programming language. Make is
the world's most commonly-used constraint-satisfaction language, and if
there's anything we know about constraint satisfaction, it's that you
sometimes have to embed procedural stuff to make it general and practical.)
So the implementor of a make-equivalent should be able to specify some
new special forms in the terse syntax:
rules
foo : bar baz bleen
quux : foo fubar
selur
satisfy quux
Keeping the grammar schema very regular may help a lot down the road. I
don't think it will limit grammars too much---irregular syntax isn't really
helpful most of the time---and in fact it seems likely to make different
apps more consistent in a very beneficial way, like a set of user interface
guidelines.
At the moment, the only thing I've come up with is requiring
beginning/ending keyword pairs, and ensuring that they can be
parsed as though they implicitly had parentheses around them. That
seems the safest route, and not very objectionable, unless somebody
figures out somehing better.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
|