This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.
On 29 May 2013 02:31:25 -0400, Mark H Weaver posted a long set of comments. One recommendation was to supporting datum comments of sweet-expressions (#; + whitespace). The idea makes sense, and I did anticipate this. However, the obvious ways imply some additional trickiness in grammar and implementation. Here's how I'm thinking about tackling this, but if anyone has a better idea, *please* speak up!! The current SRFI-110 says: "Schemeâs datum comments (#;datum) comment out the next neoteric expression, not the next sweet expression (and please donât follow the semicolon with whitespace)." Mark H Weaver recommends: "I often put "#;" on the preceeding line, which you're now asking me not to do. What is the purpose of this request? Also, "#;" becomes much less useful if it cannot comment out an entire sweet expression. Perhaps "#;" should have a similar rule as the traditional abbreviations: if it is followed by whitespace, then the following /sweet expression/ is ignored, otherwise the following /neoteric expression/ is ignored. What do you think?" I have *definitely* thought about this. Indeed, I wrote the text "don't follow the semicolon with whitespace" so that supporting datum comments of sweet-expressions could be added as a future addition. But if we add this as a *requirement* to SRFI-110, then the grammar rules and sample implementation have to be modified to handle it. For example: a b c #; e f g => (a b c g) THE CHALLENGE: Properly supporting this requires properly supporting datum comments of a sweet-expression if it is the *last* item, e.g.: fee fie foe fum #; blood Englishman => (fee fie foe fum) Handling *last* items turns out to be trickier to do, and I think that trickiness has nothing to do with whether or not the grammar is LL(1). Currently there isn't a good way to handle lines that produce no value. In particular, the "it_expr" rule *must* return a datum. In the case of lines that begin with "#!sweet", the grammar rules recurse so they can have something to return. This recursion is why the GROUP_SPLIT rule is so complicated. That approach won't work here, because the datum comment might be the last group at that indent level. So for the moment, let's say that we'll try to fix up the existing LL(1) rules instead of rewriting the grammar rules in a completely different notation. Even if we do that, I want to do that as a separate stage, and I think we should explore simplification further first. So... how could we do this? One approach would be to fiddle with all the grammar rules that invoke it_expr. However, I think that would be really ugly and involve a lot of repetition in the rules. The problem is that the calling rules each have to handle identification of the situation AND invoke a different action rule for that case. Ugh. I think a better approach would be to modify the key production "it_expr" so that it can return an "EMPTY" value, distinct from a valid datum like (), that indicates "no value at all". This would require some the action rules to handle "EMPTY" values. I think that could be handled by a few tweaked procedures, e.g., some "cons" can be replaced with "econs" (aka "empty-handling cons"): (define (econs x y) (cond ((eq? y EMPTY) x) ((eq? x EMPTY) y) (#t (cons x y)))) If we do this, one side-effect is that the GROUP_SPLIT rules could probably become much simpler. We'd no longer need to recurse deeply, because there'd be a way to signal that we saw an empty result. Thoughts? Comments? Is there a better way I'm not seeing? --- David A. Wheeler