Personally, I prefer to see the parentheses in s-expr. Maybe because that's what I'm already used to. In my opinion, however, swt-exprs could probably serve a purpose - as a representation in an EDITOR, not necessarily in the file. In fact, I would very much prefer to see swt-exprs, but I still want to hack the underlying s-exprs. And no, I don't mean mixing s-exprs with swt-exprs, but using swt-exprs as ONE representation, but if I need to hack the s-expr itself, I just tap a button in my editor and it serves it up as s-expr on demand. Sort of like using 2/2 for 1. And if I can see the s-expr of a swt-expr, I plenty darned well expect to see a swt-expr of an s-expr.
BTW the infix section in the same page mentions "'infix operator' pattern of symbols". My main concerns over using patterns are: 1. Limited namespace. One of these days I will want to make a 'convoke' infix operator (whose purpose no one these days can even imagine, because it solves a problem which doesn't exist yet), and *<=>* is just not going to convey the full meaning of 'convoke'. 2. No declaration of precedence. Which resolves first, <+& or ><-= ? If you don't declare precedence, how does the parser/editor hack the s-expr out of the swt-expr? 3. No declaration of associativity. In x <+& y <+& z, is it (x <+& y) <+& z or x <+& (y <+& z)? Again, how does the parser hack out the s-expr out of the swt-expr if it can't figure out associativity? 4. Capture of variables. I just really, really, really need to call my continuation by the symbol '++. In my opinion, an 'infix operator pattern' just makes too many assumptions about the code that will be written. I would rather have the programmer declare the infix operators he wants rather than assume that anything composed of +-*/etc. is an infix operator. Put too many rules, and you will soon need to memorize rules. In Dwheeler's http://www.dwheeler.com/readable/readable-s-expressions.html , #6.3.4, actually considers problem #2 and #3 above. It suggests getting a default, so that anyone who uses a completely new operator should explicitly put parentheses around anything else so that precedence and associativity is moot. I think an explicit way of saying where the precedence lies is better. I think #1 is the my major objection. I don't want to limit infix operators to just a set of symbols, I want infix to have the full range of the language. Incidentally, I've thought of another system of declaring precedence that would probably be better than assigning actual numbers: (definfix +) (definfix -) (definfix * :precedes '+) (definfix / :precedes '+) (definfix <- :preceded-by '+) #|assignment|# Hmm. In any case the use of abbreviations for common stuff is soundly backed by information theory: Commonly occuring symbols/code should be encoded in fewer bits/characters, because they really contain very little information.
