[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:
> 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