Kartik Agaram <a...@akkartik.com> To: dwhee...@dwheeler.com Subject: Re: [Readable-discuss] Presentation on readable s-expressions
> I notice that there's no rationale for the ( . x) rule in > http://sourceforge.net/p/readable/wiki/Rationale. Remind me, why do we > rely on this rule? Could we have an example where we need it? If it's > only really needed with sweet-exprs perhaps we can move it over to > there as a tip for certain exceptional situations? Actually, there was a short one before, but I've greatly expanded it to this: Why the (. e) rule? ------------------- Neoteric-expressions require that (. x) must mean x. This provides a simple way to escape certain constructs, in particular, some special symbols in sweet-expressions. Sweet-expressions (to be discussed) really need an escape mechanism for characters like !, \\\\, and $, and it was far easier to define the mechanism to be part of neoteric-expressions. It could have been defined as part of sweet-expressions, but that would create an implementation problem. We fully expect that implementers will work in stages; in particular, some may not want to build in indentation processing. But they might be willing to build in a neoteric-expression system into their reader. If you built a sweet-expression reader on top of a neoteric-expression reader, but that reader didn't implement (. e), then you'd have to re-implement the whole reader underneath anyway. But if all neoteric-expression readers support (. e), then a sweet-expression reader is much more trivial to build on top. It is already true that (. x) is x in guile, so there was already a working example that this is a reasonable extension. In fact, in a typical implementation of a list reader, it takes extra effort to *prevent* this extension, so this is a relatively easy extension to include. > Is example #3 formatted right? (screenshot attached) Um, no. But I wanted it to be :-). I'll try to make it actually correct next time :-). > The sweet-expr refinements seemed to come thick and fast toward the > end. Perhaps we could introduce them one at a time with examples? Or > replace the let* with an example that uses them all? Alternatively, we > could just skip refinements in this talk.. I think it's important to at least *mention* them all, and note that they're more advanced. That way, the talk at least mentions absolutely everything about the notation. It's a trade-off; I'm trying to stay less than 15 min total. --- 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
