[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI 105: Curly-infix-expressions

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.



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