There have been interesting comments on the SRFI 105 list on curly-infix notation. I'd like comment/discussion here, if there's any.
I have tried to summarize the comments here: http://sourceforge.net/p/readable/wiki/SRFI-Curly-issues/ Two smaller issues first: 1. They'd like to use "equal?" instead of "eq?" for operator comparison, e.g., to support ",op". That generalizes things, and although I have concerns about cycles, they think that shouldn't be a big concern. I'm amenable. 2. They want a directive, and John Cowan really likes #!srfi-105, dropping (enable-curly-infix) completely. Directives are fine. I'm not enthusiastic about #! being the beginning of a directive, since this is also used to start a script. But it looks like the standards body will *insist* on using #!.... for #!fold-case and #!no-fold-case, and this would be a similar kind of syntactic change. It'd be possible to have both #!...!# comments and #! directives. E.G., an implementation could say if a letter follows "#!" it's a directive, otherwise it's a #!...!# comment. That would mean that #!/usr/bin/env, #!./unsweeten, and #! /usr/bin/env would all work like now. We don't have to spec the disambiguation anyway, just state the marker and its meaning, but our rationale could note that they don't NECESSARILY have to conflict in implementations. Knowing that makes me feel less bad about #!srfi-105 as a directive. Now, the big issue: Embedded neoteric-expressions. Shiro Kawai and John Cowan are both of the strong opinion that once you enter {...} curly-infix, it should ALWAYS support neoteric expressions. Shiro Kawai said: > > 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. My concern has been that this creates a minor inconsistency; it means that f(x) would have a different meaning inside {...} than outside it. Granted, if you want f(x), you could just surround it with braces, e.g., {f(x)}. Alan Manuel Gloria also doesn't like it. HOWEVER, in the end, what is important is *adoption*. If we "stick to our guns" and make curly-infix by itself NOT support neoteric-expressions, I think it is likely we will have far less adoption. Basically, they'd like the SRFI to include "as much capability as you can WITHOUT changing the meaning of existing standards-compliant s-expressions". And their experiments show that curly-infix, by itself, isn't as expressive as curly-infix that also allows neoteric-expressions (which I believe is certainly true). So I'm of the opinion that we *should* make this change. This change doesn't affect sweet-expressions, since they will still require neoteric-expressions *outside* of curly-infix. Thoughts? Comments? --- David A. Wheeler ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
