On Tue, Aug 14, 2012 at 11:00 AM, David A. Wheeler <dwhee...@dwheeler.com> wrote: > 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.
Well, as you pointed out in the rationale, the reason for separating c-expression from n-expression is that c-expressions are one order of magnitude more backward compatible than n-expressions; there are very rare examples of existing s-expression code that is interpreted differently in n-expressions, but still have the same meaning with c-expressions. So it might be better to have an SRFI with just c-expressions, as it becomes more likely to be widely accepted and implemented. > > 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. Well, without arbitrary amounts of unread, it's difficult to separate the hash reader. comment-tag is solely for #||# and #; comments, and their existence in the hash-domain really complicates the handling of hashes. In fact, the new #! reader-option syntaxes can be implemented by having the hash reader set a flag and then return a comment-tag, as the #! stuff, AFAIK, doesn't actually resolve to any expression or datum. comment-tag can be hidden away with some sufficiently smart abstraction/indirection, but that means rewriting a good section of the codebase. Still, I think you do need some way to say "I consumed some stuff on the port but didn't yield any datum at all"; comment-tag is merely the smallest-code-size change, as alternatives require a larger backend (a backend which does not exist in the current code for that matter). So yes, you can remove comment-tag, but you'll be essentially rewriting most of the code, probably to something nearer to a monadic style a la Haskell Parsec. -- If a complete code reorg is OK with you, one thing I've been thinking of somewhat semirandomly has been to separate the parser to a tokenizer and a parser. So instead of a parser that accepts characters, it accepts tokens, like (foo bar nitz) becomes the token stream #\( foo bar nitz #\). The tokenizer handles comments and indent by itself, which solves the problem of ! working differently inside parenthesis. However, again this fails to consider the hash-domain stuff well: how do you tokenize #( a b c) for example? How about arbitrary hash-domain extensions that exist only in particular implementations? > How ready does the implementation need to be for us to start the SRFI > process? I think we just need some implementation that a full reader can call (probably providing its own read function, the way read-at-curly now works). We can then give a fuller replacement in Guile to show how it would be used / integrated into an implementation's reader. Sincerely, AmkG ------------------------------------------------------------------------------ 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
