Subject: New and Improved Lisp Syntax (was: Re: Ousterhout and Tcl lost the plot with latest paper)
From: Erik Naggum <>
Date: 1997/04/23
Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp
Message-ID: <>

[relieved comp.lang.tcl, comp.lang.functional, comp.lang.c++,
comp.lang.perl.misc, comp.lang.python, comp.lang.eiffel]

* Kelly Murray
| I propose a new dialect which has a simplified syntax, that makes it
| accessible, but without losing it's power, by adding a few simple
| keywords to replace parenthesis.  It isn't (foo 1 2) vs foo(1,2) that's
| the barrier or problem, it is having this:
|   (let ((x 10) (y 20))
|     (do ((i 0 (+ i 1)))
|         ((> i 10) x)
|      (cond ((> x y) 10) 
|            ((< x 0) 20))))
| When it is much clearer and accessible if it is written like this:

[ ugh! ]

| And has no less power than the more parenthesized version: 
| The functional view is just the same, and macros are no less powerful.

I don't think that "noise words" is the way to go.  I do think the problem
illustrated in the first version is legitimate, however.  only _slightly_
more syntax would have helped.  here's a shot:

    (let [x 10]
	 [y 20]
      (do [i 0 (1+ i)]
        (until (> i 10)
          (cond [(> x y) 10]
	        [(< x 0) 20]))

note that the "[]-thingies" mix and repeat (unambiguously) with function
calls in the body of the forms.  I think the `until' form should have a
parallell in `while', and both could of course be on their own as ordinary
conditional loops.  inside a `do', however, they would behave differently
in that the looping would involve the step-forms of the `do'.  I have never
been comfortable with the ability to include return-forms just after the
test, so I moved that after the looping construct.

the "[]-thingies" could be read as vectors, for instance.  the principle in
whether something that is enclosed in parentheses today should be in
parentheses or in brackets in this new syntax would be that parentheses be
used for forms, that is, whose first element indicate evaluation, while
brackets be used for lists that are not to be evaluated, but aid the
evaluation of the enclosing form.  the main argument for this syntax is
that (x ...) could be recognized context-freely as a _form_ and easily
differentiated from binding and constituent s-expressions.

the obvious downside of this syntax is that it would require knowledge of
the special form in which the brackets occur to be parsed correctly into
the standard Common Lisp forms.  a compiler would not have this problem.
(note that the backquote reader accepts vectors just like lists.)

hm.  now that I look at this idea that I just got while composing this
response to Kelly, I think it's good enough that I'll write a specification
and a reader for this language over the weekend.  very few forms in Common
Lisp are actually affected by it, but the extra clarity may be worth taking
a serious look at.  (yeah, so I called it NILS, sue me.)

if we work really hard, will obsolescence be farther ahead or closer?