Syntax ambiguity?

Phil Pilgrim (PhiPi)

The following code fragment compiles and runs as I expect it to:

   t.say(string("#1mae d'og~ is n/ot u k\at. its tr''{oo}. ae can pr''{oo}v it."))
   t.say(string("#0en espany/oal porfuv/or."))
   t.say(string("}#1mee p'ayrroa n/oa es] oon g'ahtoa. e es va rd'ad. pw/aydoa ]proab''arloa."))

However, if I try to comment it out with braces {}, I get an error:

{  t.say(string("#1mae d'og~ is n/ot u k\at. its tr''{oo}. ae can pr''{oo}v it."))
    t.say(string("#0en espany/oal porfuv/or."))
    t.say(string("}#1mee p'ayrroa n/oa es] oon g'ahtoa. e es va rd'ad. pw/aydoa ]proab''arloa.")) }

What's happening is that the compiler is seeing the right brace inside the string on the third line as the end of the comment, rather than the one at the end of the line. I realize the intent of the commented code could well be ambiguous. After all, which should take precedence, the braces, or the quotes? Or to put it in other terms, if the parser is inside a comment, should it be doing anything else besides looking for the end of the comment?

I really don't know the answer here. I guess my preference would be to honor balanced quotes within a comment. But that could lead to other unintended consequences. Maybe a "super comment" would be the thing for cases like this: <comment> </comment>. (I have the same problem with {{ and }}, too, so they don't help.)

Anyway, no answers. I'm not even sure what the question is. Just a comment.

-Phil

Cliff L. Biffle

So in languages like Java and C++, which don't allow nested comments, tools that excise code by commenting use the line comment //.

I think the same applies here. Most modern IDEs have a comment/uncomment button that applies/removes the line comment on selected text (hell, I distinctly remember this feature being in VB3 for Windows); I suspect there's something similar in the Tool somewhere. (I use it only as a loader, so I can't point to where.)

(I am a huge opponent of comment nesting. If the brace in your string had been an open-brace, the rest of your entire program would become a comment -- unless it parsed strings too. So then if you had a single quote, it would become a String -- unless it parsed escape characters. This goes on eternally. Comment-to-end-of-line is an easy workaround for this, though in Java it has one gotcha. Anyone in the audience who can tell me what it is gets a pony.)

(Note: there is no actual pony. But I could probably ASCII one.)

Phil Pilgrim (PhiPi)

Cliff Biffle said...
If the brace in your string had been an open-brace, the rest of your entire program would become a comment -- unless it parsed strings too.

Actually, no, this situation compiles correctly. I can only assume it's because, at that point, the compiler is processing a quoted string and that that takes precedence over any syntactically significant characters it might find in the string.

I actually like the idea of nested comments. It's a handy tool that serves a useful purpose. But there needs to be a way to disambiguate the meta-syntax used by these comments from the syntax of the language itself. In a language like Spin that's line-oriented (as opposed to being free-form like Perl), this could easily be accomplished by requiring that nested comment openers and closers occupy the entire line, rather than being embedded within a line with other code. In Spin, this might look something like this:

{{{
   t.say(string("#1mae d'og~ is n/ot u k\at. its tr''{oo}. ae can pr''{oo}v it."))
   t.say(string("#0en espany/oal porfuv/or."))
   t.say(string("}#1mee p'ayrroa n/oa es] oon g'ahtoa. e es va rd'ad. pw/aydoa ]proab''arloa."))
}}}

There can be no ambiguity here, since you can't split program statements between lines.

There's still room for the embedded nested comments, too, in places like this:

  case this
    "l" {Lot} : set(formant(310, 1050, 2880, 3500), 0, 0, 200, 50)
    "w" {Wad} : set(formant(290, 610, 2150, 3500), string(QT), 0, 50, 200)
    "y" {Yet} : set(formant(310, 2020, 2960, 3500), string(QT), 0, 100, 200)
    "m" {Mom} : set(formant(480, 1270, 2130, 3500), string(QT, GA, 5, NA, 5, NF, 14), 10, 200, 30)
    "n" {No}  : set(formant(480, 1340, 2470, 3500), string(QT, GA, 5, NA, 5, NF, 14), 10, 200, 30)
    "p" {Pot} :
      set(formant(400, 1100, 2150, 3500), string(QT), 0, 100, 0)
      set(0, string(QT, AA, 60), 0, 10, 10)
      set(0, string(QT, AA, 20, NA, 50, NF, 20), 100, 100, 100)
    "b" {Bad} :
      set(formant(200, 1100, 2150, 3500), string(QT), 0, 100, 10)
      set(0, string(QT, GA, 10), 10, 40, 10) 
    "f" {Fit} :
      set(0, string(QT), 0, 30, 0)
      set(formant(19, 38, 57, 57), string(QT, FA, 2, FF, 250), 0, 200, 0)
      set(formant(470, 1120, 2430, 3400), String(GA, ZERO), 0, 1, 50) 
    "h" {Hit} : aspirate := true
    "v" {Vat} : set(formant(220, 1100, 2080, 3500), string(QT, FF, 250, FA, 2), 0, 100, 200)
    "j" {Jot} : set(formant(260, 2070, 3020, 3500), string(QT, GA, 10, FF, 100, FA, 10), 0, 150, 100)

There is no other reasonable way to accomplish what the {}'s do here for readibility.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 11/8/2006 3:49:08 AM GMT

Cliff L. Biffle

Phil,

Don't get me wrong -- I'm not saying there should be no inline comments. Simply that, for disabling blocks of code like you're doing, line-oriented comments make life much easier.