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



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.