Subject: New and Improved Lisp Syntax (was: Re: Ousterhout and Tcl lost the plot with latest paper) From: Erik Naggum <erik@naggum.no> Date: 1997/04/23 Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp Message-ID: <3070821916847636_-_@naggum.no> [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])) x)) 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.) #\Erik -- if we work really hard, will obsolescence be farther ahead or closer?