[I'm crossposting this to comp.lang.dylan, since that group has some
experience with adding a more familiar syntax to a scheme-like language.]
In article <4cgbbj$slm@nkosi.well.com>,
Darius Bacon <djello@well.sf.ca.us> wrote:
>
>Paul Wilson proposed a syntax for shell programming:
>> 1. Common special forms like IF use balanced keywords (maybe palindromic,
>> as above, maybe not) which act as implicit parentheses as well as
>> specifying which special form is meant.
>
>I think you can get the benefits of this idea with a loop-macro style of
>syntax, like so:
>
>(define (gosh wow)
> (let (x = (* wow wow))
> (y = 42)
> in (if foo
> then (+ x y)
> else (- x))))
I'm not sure most people will go for this. It's easier to visually
match if and fi (or if and endif, or whatever) than it is to count
parentheses forwards and backwards to see if they match. I think we
should assume that many people will not be using a nice editor to
edit a trivial script. (I'm not arguing that people *should* use
lame editors, just that they *will*, and this is particularly important
for just typing in commands at a shell.)
I also think it's best if nested expressions don't need parentheses
in most cases, e.g., that a line break acts as a separator that implies
a sequence.
An example:
def (mygosh wow)
let (x (* wow wow)) ; or maybe: let x = * wow wow
(y 42) ; y = 42
in if foo
then display "foo: " foo
+ x y
else display "no foo!"
- x
fi
tel
Juggling all these desiderata requires careful thought about grammatical
ambiguity, and may require a funky reader integrated into the parser.
(This is aggravated by the desire to have a shell interpret an unbound
variable in function position as a command to run a program, and backquote
its argument list.)
You may not be able to just read whole expressions and then parse them
as Scheme compilers generally do. (That is, a two-level parse of surface
syntax and then deep-syntax-and-semantics-interpretation.)
One way around this may be to use a more conventional left-to-right,
recursive-descent parse, so that when you hit a keyword you can modify
the grammar to recognize matching delimiters. The idea here is that
when you do hit a symbol, you determine its syntactic role by looking
up its binding. Then that tells you how to continue the parse, by
updating the "parsing environment" and maybe even the "reading environment".
The left-to-right parse ensures that by the time you see a symbol,
its syntactic role is apparent because the earlier symbols will have
had their effects on scope, etc.
This is the kind of thing the RScheme lexically-scoped syntactic extension
facility is designed for. Instead of macroexpanding as a conceptually
separate pass, it's integrated right into the compiler in a clean way.
The normal SICP-style compile-time environments are extended to handle
the funny scoping issues that come up when you write "hygeinic macros",
rather than requiring the macroexpander to do a bunch of the same scope
resolution work that the compiler already does. (E.g., to notice that
lambda does funny things to the meaning of identifiers.)
We haven't really addressed all of the issues in supporting infix syntax yet,
but it seems like our approach could be extended very naturally in this
direction.
>This assumes what makes parenthephobes go `yuck' is the spareness of prefix
>notation with positional arguments, not the parentheses themselves -- as the
>success of Tcl suggests. People might want an `infix' macro, too, as in
>(infix x * (f x) + y * (f y)).
Yes, but I'd even like to avoid that, if possible. Haven't figured
that one out yet... At the very least, it seems that we could just
use a different kind of bracket [x * (f x) + y * (f y)] around simple
infix expressions.
>(I prefer Scheme just the way it is, btw.)
>
>>So you end up with things like [set $a $a+1].
>
>set a [expr $a+1], not that that affects your point.
I think it reinforces my point quite nicely. Tcl manages to combine an
amazing number of of the worst features of many languages. It doesn't have
a clear syntax, and it doesn't have a simple one, and it requires you to
distinguish between expressions and statements for no reason at all, and ...
On the one hand, this gives me reason to hope that people will recognize
a better language when they see it, as long as it's vaguely familiar-looking
and well-explained. On the other hand, Tcl is already established
in a lot of places, so something that replaces it should be *much*, *much*
better to ensure that it succeeds. It's not hard to do *much* better,
but the second *much* takes some careful design :-)
>__
>Darius Bacon http://www.well.com/user/djello/
--
| 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/)
|