This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.
I was writing a reply explaining what points I felt terrible about c-exprs, but you summarized them well in your new message, so I can just rephrase them: - Mentally parsing mixture of c-exprs and s-exprs are hard, especially when they appear alternatingly. - S-exprs works better in multi-line expressions. (C-exprs is more verbose (in n-ary cases) and that makes it worse.) N-exprs address these issues, as you said. I think T-exprs also helps a lot to alleviate the first problem, since it tends to strip the "outer" s-expressions and reduces the need of flipping switch of the mental parser. Without the support of n-exprs, probably c-exprs would be used only for small, leaf expressions. Whether it is still worth a troulbe or not is debatable; I wouldn't support c-exprs alone. C-exprs and n-exprs are technically orthogonal, and you split them partly because for the ease of adoption. But I feel that combining them increases their appeal a lot for wider adoption, while supporting only one doesn't seem likely. Supporting n-exprs only in c-exprs may seem technically inelegant, but how about seeing it as a starting point? To me it seems easier to flip switch once I enter '{}' world, so I don't mind if the syntax is different in '{}' from outside '()' world. Plus, the full n-expr is upper compatible to "n-expr inside {}", and it may be easier to discuss after people get experience using n-exprs in {}. Or, supporting full "readable" project once is also easier than supporting individual elements. I read the full sweet expressions as a totally different syntax; again, no need to flip the switch often.