Lambda the Ultimate

You can use a symbol followed by an "empty group" - () to indicate that you're invoking a function with 0 arguments. ((a)) will be written like this -
(a()()). If its on its own line, you can just write a()().

The "exceptions" section is at the very bottom of my description page and describes this case.

ah, ok. But it might be good if you could find a way towards backvards compability. By that I mean that it would be good if ez did ressemble a super set of regular lisp syntax, so that you can freely intermingle both styles.

In a way, you can already intermingle lisp style code to some extent in this ez syntax. You just have to remember that () means "grouping" and therefore repeated bracketing gets you nothing different.

(let [(a (+ x y))] (* a a)) 

Means the same thing in ez syntax as it does in scheme.

The expression (symbol) can be substituted by symbol even if its on its own line. They mean the same thing. The "empty-group" notation is the one that indicates that the symbol is to be evaluated as a function.

IIRC, M-expressions were not compatible with macro expansions. Which leaves the question open whether any non-parenthesis derivative of lisp can ever be as powerful as S-expressions?

What I've written is a syntax transformer from the ez syntax (lets call it that for now) to lisp s-expressions. It makes no assumptions about what those s-expressions mean. Therefore you can very well write macros in ez syntax that operates on the ez syntax expressions. For example -

defmacro swap2 (x y)
    list y x

will translate to

(defmacro swap2 (x y)
    (list y x))

and since every subsequent occurrence of swap2 a b will be translated to (swap2 a b), the macro will be invoked by the lisp reader.

Why do you say that non-sexpr syntaxes (including M-expressions) are incompatible with macros? In fact, one of the reasons I bothered to write the translator is that I won't lose macros.

I intended this "ez" syntax for human entered and read code. I did not intend data I/O to be performed using this syntax. Hence read and write are no longer inverses purely within this "language". However, there's no harm in read and write using sexpressions in order to retain their inverse nature for data I/O and use this syntax only for the load function.

I can very well imagine a pretty printer for sexpressions which will print out in this ez syntax. Therefore theoretically read/write *can* be inverses as well. Its a question of whether its desirable, however. I'd personally prefer the rigor of sexpressions for data transmission.

My purpose in writing this translator is to provide a stepping stone for getting into lisp if you're the kind to be influenced by syntactic sugar. The translator makes it easy to see how much of other languages is merely syntactic sugar for lisp sexpressions.

...but a more useful facility might be to write translation both ways. That is, it should be possible to take any Scheme code and display it in the form of ez syntax. Not only would you make it easier to write Scheme code, but you should have the advantage of allowing novices easier access to others Scheme code.

On the plus side, this would allow you to run translations back and forth to prove that the translation is correct. On the downside, it's possible that you might end up with a bablefish effect where you run text back and forth between languages and end up with text that loses its original meaning.

I think that should be quite easy to do in scheme using the built-in reader. Like a pretty printer or something.

.. reserved for another weekend :)

I consider that a complement :)
...but its no accident. The : notation for the "dotted pair" is a silent tribute to Haskell syntax :)

I'm happy enough to use the parentheses notation.
I did this for those who would like to try lisp/scheme but are scared shit of the parentheses explosion.

Some others who've previously designed such syntaxes have said something similar. It seems likely that this is at least a factor in the failure of these syntaxes to gain traction — who wants to use something that's disclaimed by its author at the time of its creation? There are many related factors, e.g. who's going to fix problems found in practice.

Gambit Scheme also has a syntax called six-script, some small examples of which can be seen here. [Edit: make that one small example of which.]

More Lisps: Arc (see point 5) and Qi (which has syntax for pattern-matching).

"The Evolution of Lisp" by Steele and Gabriel, pp. 82-5: "The Syntax Question" is excerpted from this.

More SRFI 49 flamage (and my own measly tuppence (part 2)).

I found it rather strange that an SRFI existed for this as you point out.

After these discussions and some more searching, I'm getting a bit tired really. As far as I can tell, I've shown a reasonably minimal solution to the "accessibility problem" of lisps - for all lisps in question (well, except the backquote notation which is pending).

So at the very least - if someone says "I'm scared of lisp's parentheses" - I'd say, "well you can use this equivalent thing instead". Paul Graham, for all the respect I have for his popularization of lisp, has the luxury of musing on these issues for an unbounded time interval, but I'd rather have a usable solution now than be asked to breathe hope instead.

(well, except the backquote notation which is pending).

Backquote notation is pretty critical if you want to support Lisp, and not just a fixed Lisp subset. As I'm sure you know, the standard Lisp macro system, and a number of Scheme macro systems, depend on backquote notation.

S-expressions are a way of representing arbitrary syntax trees, not just (standard) Lisp syntax. For example, it's easy enough to support expressions such as the following in Lisp:

(+ (infix (x + y) * z) (postfix z y / x -))

...where the syntactic rules in each of the major subexpressions are different. A critical question for any general-purpose alternative Lisp syntax is how well it supports such embedded sublanguages. Many such sublanguages are commonly embedded in Lisps, including XML, general logic languages, more constrained rule-based languages, data definitions of all kinds, etc. To support these sorts of applications properly, you're almost certainly going to need a way to define new syntactic sugar, since operators such as ":" and "::", with their specific precedence rules, are only going to be appropriate in specific contexts.

So at the very least - if someone says "I'm scared of lisp's parentheses" - I'd say, "well you can use this equivalent thing instead".

Ignoring the issue that it's not yet equivalent, those people would have some valid reasons for being cautious about adopting such a syntax. The biggest one is that until someone can demonstrate that non-trivial programs have been written and maintained using the syntax, and that it was found viable during that process, its viability is not certain.

For example, one issue I see with the syntax is that rearranging of code seems to change the punctuation requirements, such as when changing a multi-line list to appear on a single line, commas need to be inserted. That's not a great property for a syntax to have, since rearranging of code is common. Other issues like this may not become apparent without significant experience with the syntax.

Useful alternative syntaxes are possible, but it's a much more subtle problem than it might appear at first.

I agree in general.

Regarding the backquote notation, I do understand its significance, even though I think it can be implemented as a macro itself (though less compact). For example -

(template Hello members of (unlit group) - (unlit-splice (map member-name list-of-members))

which could expand to -

(append (list 'Hello 'members 'of group '-) (map member-name list-of-members))

The indentation based syntax is not as rigorous and consistent as s-expressions, but I don't see people complaining about a similar rearrangement problem with Haskell's syntax. In a way, by making the syntax similar to Haskell, I've tried to borrow the work done by others in proving it in the field.

I believe we always play to the strengths of our tools as long as they don't hinder us. Being able to define infix operator macros is quite a nice feature I think :) If we assume "macro" defines macros like "lambda" defines functions (like in a dialect I use), we can write -

$ := (macro (a b) (list a b))

to define the haskell "apply" operator '$' that collects everything to its right before applying. So that (f $ sum alist) expands to (f (sum alist)). That just duplicates '::', but it shows how you can invent it in the language itself.

Thanks for those great links! In particular, the SRFI for an indentation sensitive syntax is pretty darn close to what I've come up with, though there are still some rough edges there like lack of infix notation and the use of 'group'. Maybe I should propose this "ez" syntax there instead.

I use PLT Scheme regularly and I don't know how I missed Honu. I can't figure out what I'd use it for at the moment though.

I'm not worried about other languages/runtimes with such syntax. I just want to make all lisp dialects accessible using this syntax.

Now I see what's generally meant by "alternative lisp syntaxes break macros". But you do say "to maintain an *obvious* relationship between code and AST". I suppose alternative syntaxes fall into a continuum with varying degrees of obviousness in this connection. I do see that this syntax , by introducing infix notation, lowers the obviousness of this connection when using s-expressions.

.. but I do feel its not to far off - at least not as far off as infix notations with precedence rules, where a * b + c and a + b * c, though formally similar, yield different ASTs.

Lisps use infix notation too btw - the "dotted pair". Syntactically, (a . b) is a 3 term s-expression which gets read in as a cons pair.

Introduce syntax for syntactic templates (quasiquotation), both as expressions for construction and as patterns for pattern matching.

As a side effect, this appropach (compared to representing code using naked Lisp lists) allows for hygiene and source location tracking.

I actually like that proposal, but I'd like to see what he'd get to, if it weren't for goal 6 on his "paper":

Backward-compatible. Ideally, it should be able to read regular s-expressions (at least normally-seen formats of them) as well as the extensions. I’m willing to give a little on this one where necessary.

To me, this just seems too tall a goal, it certainly limits the options.

.. to quote Jeff Raskin.

Apart from the fact that lisp syntax has been growing on me particularly after I stumbled on DrScheme (I can't praise those guys enough), the following (using ez2scm) looks better to me than Wheeler's proposal -

define (factorial n)
    if (n = 0)
        1
        n * factorial (n - 1)

You can even do the "right thing" -

define (n !)
    if (n = 0) 
        1 
        n * (n - 1)!

... and from the compatibility point of view, ez2scm will parse the following correctly as well -

(define (factorial n)
    (if (= n 0)
        1
        (* n (factorial (- n 1)))))

for that type of program so I never played with it, but one of the marketing claims I remember was

"It's written in C so it's far faster than the older LISP-based CA systems".