Shiro Kawai:
> Yes, but I prefer denser code and sometimes I drop those
> whitespaces to avoid the expression spill over to the next line,
> so turning on n-exprs outside {} is dangerous for my code base.
>
> Plus, my mental parser is trained to see f(x) as two items f and (x)
> when it's in "s-expression" mode, so mixing s-exprs and n-exprs
> wouldn't work for me.

:-).

Well, this is why I thought we should start with curly-infix.  At least {...} is explicitly *not* defined by a standard, so any definition of it can't conflict with the official portable spec.  Neoteric-expressions *outside* of curly-infix, and sweet-expressions, certainly *do* change the syntax, so I believe they are a steeper climb.

> Have you written code mixing s-exprs and n-exprs *without* using
> c-exprs and t-exprs?  If so, how did it work for you?

Yes, and that's a fair question.

I looked hard at and did a lot of experimenting with SRFI-49, which *ONLY* does indentation and *nothing* else.  I make a small pretty-printer, and ran a lot of code samples through both ways.  In fact, the sweet-expression rules are based on SRFI-49, though they're not the same.  We ended up making a number of changes based on problems we had trying to *use* them to write actual code.

In addition, I also did some other experiments early on.  This was primarily hand-experiments, just taking existing code fragments & transforming them into various possible notations (without trying to implement a parser in those cases).  For a while I tried to "automatically" detect infix and frankly, that was a disaster that I eventually gave up on.

The SRFI-49 experiments convinced me that indentation processing works really nicely to simplify major structures.  Which is no surprise; people *already* use indentation this way.  Indentation processing doesn't help leaves, and real code has a lot of leaves. Again, no surprise, nobody indents trivial s-expressions.  In contrast, curly-infix and neoteric-expressions are really helpful in simplifying leaves, which makes the whole thing work well together.

That said, I think curly-infix is a good step forward, if you're not willing to go all the way to sweet-expressions.  The big difference is that curly-infix, by itself (or with neoteric inside), do NOT require a syntax change meaning to portable code.   Traditionally-formatted code has a lot of leaves, too, and I think you get significant benefits even if you don't go "all the way".  It's also a plausible stepping stone; I think many people will be more willing to use the full sweet-expression stack once they've had experience with the rest.

--- David A. Wheeler