Alan Manuel Gloria <almkg...@gmail.com> > 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.
Okay. So, let's start with the curly-infix SRFI. I've gen'ed one up already. I think we ought to wait briefly before submitting the neoteric one, so that if there are procedural problems, we won't repeat them the second time. > > 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? As far as cleanup goes, the "clean" functions for sweet-expressions is probably unnecessary at this point, and at the least, I'd like to remove them. But I'm not sure that we want to reorg the direction you've outlined. Being able to recurse and do the problem as-you-go is normal for readers; that kind of split would make it more complex than other readers, and simplicity and familiarity are valuable. Traditionally, when the #-reader encounters something that turns out to be a comment or delimiter, it just recurses to get a value. This *would* work in curly-infix and neoteric-expressions. Ah, I think I understand the issue better now. The problem is that in sweet-expressions, if you're in the hash reader, and you read a comment, you want to recurse to *some* reader, but it's not always clear which one. So the current code passes that info back up, for someone else to figure out. Here are examples? ; Indentation active after #-comment read: #| comment |# foo bar bat => (foo bar bat) ; Indentation inactive after #-comment read: foo ! bar #| comment |# bat big => (foo (bar bat big)) Do I have it now? The obvious alternative is to pass that info down the call chain (new parameters everywhere!); that'd eliminate the problem. Adding new parameters everywhere is not always a great answer, but in our case, we're *already* passing the "other reader" down; couldn't we use that? When implementation is complicated, I also look to see if we can redefine the spec to make it easy. I'm not sure that's possible in this case, though it'd be great if it was. > > 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. Ah. Well in *that* case, we've got that right now. --- 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
