error: alternative doesn't exist in section AST (even though it looks like it does)
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
error: alternative doesn't exist in section AST (even though it looks like it does)
by Ben Evans-2
::
Rate this Message:
|
|
|
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Etienne M. Gagnon
::
Rate this Message:
Hi Ben,
I agree with Chris. Another possibility is that you forgot to name and transform some CST alternative: declaration = {use} ... {-> ...} | ... | alternative name forgotten with no transformation // unnamed and not transformed ; ... Abstract Syntax Tree ... Etienne Christopher Van Kirk wrote: > Seems like you're attempting a CST to AST transformation to declaration with no subtype info specified like: > ... > -- Etienne M. Gagnon, Ph.D. SableCC: http://sablecc.org _______________________________________________ SableCC-Discussion mailing list SableCC-Discussion@... http://lists.sablecc.org/listinfo/sablecc-discussion |
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Ben Evans-2
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Niklas Matthies
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Etienne M. Gagnon
::
Rate this Message:
See below. In SableCC there's a potential collision with empty alternatives of course. But a viable solution could be to disallow unnamed empty alternatives -- which are probably likely to be errors anyway. That's an interesting proposal, but I don't think that it could work within SableCC 4. Let me explain. SableCC 4 allows for multiple unnamed alternatives in a single production. This is in line with SableCC 4's new philosophy of: you only need to name it if you need to refer to it and its default name is ambiguous (or missing). Example: some_prod = some_prod child | ; // notice the empty second unnamed alternative
child = {minor} ... | {adult} ...;
In SableCC 3, this would raise an error, as two alternatives of
some_prod are unnamed.SableCC 4 allows for it. Now, once the AST is built, it won't have explicit types for both alternatives. In other words, you won't be able to access some_prod alternatives using an in/out/caseASomeProd() method. But, and that's the idea, the AST will contain the nodes, so you'll be able to use in/out/caseAMinorChild() and, therefore, have access to all "child" nodes of the AST. So many people complained about how SableCC was painful to use because it forced you to name everything. This prompted me to relax SableCC 4's naming requirements while preserving good behavior: instead of allowing for index-based access, SableCC keeps named-based access but denies direct access when no unambiguous name is provided. Of course, this philosophy gets in direct conflict with your otherwise quite interesting proposal, as illustrated by the example above. I think that keeping relaxed naming will be of greater benefit to SableCC 4's users. What do you think? Etienne -- Etienne M. Gagnon, Ph.D. SableCC: http://sablecc.org _______________________________________________ SableCC-Discussion mailing list SableCC-Discussion@... http://lists.sablecc.org/listinfo/sablecc-discussion |
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Niklas Matthies
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Etienne M. Gagnon
::
Rate this Message:
Hi Niklas,
See below. > I think that it may still be okay to require that empty alternatives > have to be made more explicit in some way. This would also benefit > readers of the grammar. Stuff like "= |" or "| |" or "| ;" or "= ;" > isn't exactly readable, it's easy to overlook or misread. Maybe > provide some sort of epsilon symbol? > If it can make you happy, in the lexer, this is the case in SableCC 4; you have to write '' to get an empty string. The problem with parsers is that empty alternatives are a standard idiom used in almost every compiler book out there (for implementing lists using recursion). Of course, SableCC's best practices are to use multiplicity operators (e.g. *, ?) instead of empty alternatives, but SableCC has to remain appealing to new users that haven't yet learned about such practices. Also, it is convenient to be able to easily rewrite an existing grammar that doesn't use operators in SableCC's syntax. SableCC 4's name requirements relaxation help much in that direction. Your main incentive for disallowing empty alternatives seems to be related to errors. SableCC 4 is not SableCC 3. It won't report errors at "line 0 position 0"! A spurious empty alternative in the CST that has no match in the AST will get a precise error message. As for conflicts resulting from empty alternatives, they will clearly identify the problem : the conflict has to involve a reduction of the empty alternative (it can't be a shift)! Two empty alternatives in the concrete grammar automatically cause a conflict. So, there you go: errors related to empty alternatives will be easy to locate. If empty alternatives were not as widely used, I would agree with you to force users into using some keyword to identify them, but given the current state of things, I think that it is best to allow them without requiring any special syntax. Etienne -- Etienne M. Gagnon, Ph.D. SableCC: http://sablecc.org _______________________________________________ SableCC-Discussion mailing list SableCC-Discussion@... http://lists.sablecc.org/listinfo/sablecc-discussion |
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Pete Poulos
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Pete Poulos
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Etienne M. Gagnon
::
Rate this Message:
Hi Pete,
See Below. What if you had a flag or option the user could turn on disallow empty expansions for those who are interested in it? That won't answer the original request to allow for trailing "|".
Why not put the '=' on the next line, e.g.some_production = x y z | a b c | d e f ;But, again, this doesn't solve the problem of getting identical layout for all alternatives. The only real solution is to use a grammar formatter. Such a thing could even add some standard comment in the body of an empty alternative to help users see them. A formatter could be written as a separate software, or even be better, written as an Eclipse plugin... I'll let you guys work on that. :) PS: can we get a rough estimate on when we can expect to see sableCC 4? Ah! The dreaded question... I am aiming for the beginning of Summer. Etienne -- Etienne M. Gagnon, Ph.D. SableCC: http://sablecc.org _______________________________________________ SableCC-Discussion mailing list SableCC-Discussion@... http://lists.sablecc.org/listinfo/sablecc-discussion |
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Niklas Matthies
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Niklas Matthies
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Etienne M. Gagnon
::
Rate this Message:
Right. But imagine the following situation. A new user comes in and
writes: opt_ident =
ident |
/* empty */ ;
Of course, as usual, SableCC would ignore the comment. Now, with your proposal, SableCC would ignore the trailing "|" and thus treat this production as a single alternative one. Worse: Maybe both the CST and AST use the same layout. So, it will get past through all checks. It's only later, at usage time, that end-users of the parser will notice that the ident is not optional. It is easy to add an Empty keyword. It's more difficult to keep users from harming themselves by forgetting to write it explicitly. Etienne -- Etienne M. Gagnon, Ph.D. SableCC: http://sablecc.org _______________________________________________ SableCC-Discussion mailing list SableCC-Discussion@... http://lists.sablecc.org/listinfo/sablecc-discussion |
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Pete Poulos
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Niklas Matthies
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Etienne M. Gagnon
::
Rate this Message:
Hi Niklas,
See below. > I'm semi-convinced. Of course silent errors can happen all the time, > like an accidental '||' instead of '|', or a forgotten '?', or indeed > writing '(a|b|c|)' instead of '(a|b|c)' in a regex (which is something > that does happen[1] -- quite an amusing read). But the above could > really be hard to spot for someone who's been accustomed to that > pattern. I don't know. > There is a huge difference in the impact of an erroneous trailing "|" left by error in the parser (leading to a spurious empty alternative), and the same thing in a lexer. For one thing, the parser needs an unambiguous parse. This restricts the use of empty alternatives. The good thing is that empty alternatives are quite good at generating conflicts. Second, as SableCC constructs an AST, there will be a chance to notice the spurious construct in the generated AST & tree walker classes (e.g. visitors). As for lexers, they don't care about ambiguity; they only care about matching. This means that once something is matched, no knowledge is kept as how it actually matched. e.g. word = letter* | 'thisisaword' | 'thisisanotherword'; The "word" token will match the string "thisisaword". Now, whether it matches it as a "letter*" or as "'thisisaword'" is not known. But, SableCC 4 does protect users from spurious "|" in lexers: some_token = 'a' | 'b' |; // error! Instead, you have to write: some_token = 'a' | 'b' | ''; This is quite acceptable, as a lexer is string based. So, it makes sense to represent epsilon as an empty string. Now, unfortunately, we can't extend this to the parser grammar: Parser some_prod = '' | // alternative with one token element ; // empty alternative As SableCC 4 allows for literal tokens in the parser grammar, the above two alternatives are really distinct. If there was an intuitive solution that wouldn't result in "surprises" for new users that DON'T READ THE ******* DOCUMENTATION, as usual (!!!!), then I would accept it. But, I haven't found one, and your proposal would be surprising to new users. Really. I'm all in favor of "no surprises". I leave other parser generators to surprise grammar writers or (more likely) parser end-users with hidden side effects on conflict resolution and other "features". But, thanks for the neat suggestion. :) Etienne -- Etienne M. Gagnon, Ph.D. SableCC: http://sablecc.org _______________________________________________ SableCC-Discussion mailing list SableCC-Discussion@... http://lists.sablecc.org/listinfo/sablecc-discussion |
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Etienne M. Gagnon
::
Rate this Message:
Actually, a solution would be to use an "alternative terminator"
instead of a separator. Something like:
some_prod =
{alt} some alt elements ; // ";" being an alternative terminator
{other} other elements ;
; // empty unnamed alternative
a b c ; // unnamed alternative
;; // ";;" being the production terminator
With such a proposal, we get identical layout for all alternatives, but
I simply don't like it. As for considering "|" as a terminator, I won't
buy it. We have to deal with the legacy of hordes of programmers
knowing "|" as a binary operator (e.g. separator).OK, let's kill this thread, unless somebody has a really distinct proposal that is likely to be accepted. Etienne -- Etienne M. Gagnon, Ph.D. SableCC: http://sablecc.org _______________________________________________ SableCC-Discussion mailing list SableCC-Discussion@... http://lists.sablecc.org/listinfo/sablecc-discussion |
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Niklas Matthies
::
Rate this Message:
|
|
|
Re: error: alternative doesn't exist in section AST (even though it looks like it does)
by Niklas Matthies
::
Rate this Message:
|
signature.asc (265 bytes) | < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
