Alan Manuel Gloria: > We should probably hold off on the full t-expression stack until after > the 1.0 release, but how about another SRFI for the n-expression level?
N-expressions are definitely ready for the SRFI process too. If we're going to do both curly-infix and neoteric now, how about proposing both as a single SRFI? Then we can use the module name "readable" too. That would reduce everyone's work - 1 SRFI would cover two of the 3 parts. I could tweak SRFI-Curly to do that. Then we could introduce a separate SRFI for sweet-expressions, later after we've had more experience with them. That second SRFI could add, to the module defined in the first SRFI, the items specific to sweet-expressions. We could hint that sweet-expressions are expected later in the first one. Both curly-infix and neoteric are ready, in the sense that we know what they do. However, SRFIs require submission of an implementation. We have one, though clean-ups and improvements are needed. I know that the underlying reader, for example, doesn't quite meet spec (though it's close enough to read lots). Also, comment-tag is clunky; I'm not entirely convinced it's *necessary*, even for sweet-expressions. How ready does the implementation need to be for us to start the SRFI process? --- 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
