There seem to be two major approaches to making Lisp "easier to read":
* Macros, primarily for infix support.
* Modified reader (e.g., sweet-expressions).
I think that through careful definition these approaches can work together.
Each has their advantages. An infix macro is better for sophisticated
precedence and ordering support. A modified reader can simplify presentation
and eliminate many parentheses that a macro-only approach cannot, it enables a
single interpretation that "works everywhere", and it doesn't require constant
reference/use of the macro.
My thought is that the sweet-expression reader should have strict rules on
"what it will treat as infix", and anything else will be "passed through
as-is". That means that if an expression uses infix operators beyond what the
sweet-expression reader can handle, just surround it with the macro call, and
the macro call will see the original list (so IT can process it).
My proposed narrow rules for sweet-expression infix detection:
1. Must have an odd number of parameters >= 3 (otherwise you don't have enough
parameters to HAVE an infix operation)
2. The second parameter matches the infix pattern ("and", "or", or only certain
punctuation)
3. The odd parameters do NOT match the infix pattern. So {a * - b} will NOT be
processed by the sweet-expression built-in infix handler
4. All even parameters are equal, e.g., {1 + 2 + 3 + 4} becomes (+ 1 2 3 4).
So {2 + 3 * 4} will just become (2 + 3 * 4) which will hopefully be later
processed by an infix macro.
A list that doesn't meet these criteria are passed on as-is, without an error
message (for possible later manipulation by a macro).
A disadvantage to this is that "bad" expressions won't be detected by the
sweet-expression reader - instead, they'll be passed through to an infix macro
processor (which might not be used!). However, "bad" expressions are ALREADY
undetected by Lisp processors (Lisp doesn't do that kind of checking normally),
so this is nothing new :-).
--- David A. Wheeler
