Email list hosting service & mailing list manager


Re: SRFI 105: Curly-infix-expressions David A. Wheeler 29 Aug 2012 23:40 UTC

Shiro Kawai:
> 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 {}.

Excellent points.  I am carefully considering this.  I know John Cowan is for this, and that Alan Manuel Gloria does not like it.  Anyone else?

> 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.

It's not a totally different syntax, though it can *look* that way.  Once you enter (...) or {...}, the indentation processing of sweet-expressions is disabled, so typically-formatted s-expressions work just find in a sweet-expression reader.

Similarly, a neoteric-reader will read normally-formatted s-expressions without change.  Of course, it will interpret f(x) differently, but that is a very uncommon format for a traditional s-expression.

--- David A. Wheeler