I said: > > 2. In an earlier email discussion we discussed how to interpret > > "(head|empty) DOLLAR comment_eol"; the current BNF production reflects > > that. However, I'm now leaning toward making that be an error.
John Cowan: > I agree again. I think it's very important not to fall into the trap > of "Well, this syntax has no current meaning, but I see how it could > possibly mean X, so let's make it mean X." In such situations, I think > it is far better for the syntax in question to be an error. If every > possible syntax is meaningful, then there is no hope of intuitive error > detection, still less error correction, an important property of a truly > readable syntax. Yes indeed. I think unless Alan Manuel K. Gloria (or someone else) makes a strong case for keeping things as-is, "DOLLAR comment_eol" is going away. We should document this (and why) in the SRFI, whatever ends up happening. > For the same reason, I am opposed to the "<* ... *>" syntax. We already > have a way of doing this, even if it's imperfect, and we should stick > with that rather than adding yet another complication. That syntax > should either be an error, or these forms should be ordinary identifiers. I'm more bullish on their prospects, since there *are* use cases. It's certainly possible to reserve "<*" and "*>" instead, so that they can be optionally added later. If we don't actually add them, I think we should at least reserve them. The good news is that <*...*> is completely separable from everything else. So let's focus on the rest of it, while I experiment with <*...*> semantics. Then we can have a separate thread on just <*...*>, aka "RESTART", since nothing else depends on it. --- David A. Wheeler ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
