| [TCS] Multiple "operatored" templates conflict [message #377469] |
Tue, 08 May 2007 05:45  |
Eclipse User |
|
|
|
Hello again.
Either I found a bug or I am doing something wrong.
In the language I'm trying to parse using TCS there are two kinds of
expressions, arithmetical and logical, that should never mix. I implemented
them in TCS in the following way.
For arithmetical expressions
- A primary "Value" non-terminal
- An abstract Expression nonterminal, "operatored", extended in three ways:
- an ActualValue, itself containing a Value
- an OperatorExpression (operatorTemplate) with operators + - * /
- a SubExpression, an Expression encolsed in parenthesis
(operatorTemplate again, because it is left recursive)
For logical expressions:
- A primary "Term" non-terminal
- An abstract LogicalExpression nonterminal, "operatored", extended in three
ways:
- an ActualTerm, itself containing a Term
- an OperatorLogicalExpression (operatorTemplate) with operators "or"
"and"
- a SubLogicalExpression, a LogicalExpression encolsed in parenthesis
(operatorTemplate again, see above)
Now, if I test those two parts of the grammar (by setting Expression or
LogicalExpression as the main template) the parsing goes well. However, if I
have a non-ambiguous rule producing either an Expression or a
LogicalExpression, in both cases there are problems parsing the expression.
I tried tracing the parser and found out that it is expecting the correct
type of expression (so this is not an ambiguity problem), but for some
reason when it reaches the point of parsing the "primary" expression
non-terminals, it always expects one of the two types, never the other,
regardless of the expression type it had started expanding in the first
place.
For example, it may start expanding an Expression and ending up expectng
Terms (LogicalExpression primaries) or vice versa. Oddly enough, it seems to
depend on the ANTLR compilation that randomly produces parsers recognizing
either Terms only or Values only, regardless of the expression nonterminal
expanded.
The compiler does not issue any error or warning, so I am clueless. Is this
a bug?
Thanks.
--
Lorenzo
|
|
|
|
|
|
|
|
|
|
| Re: [TCS] Multiple "operatored" templates conflict [message #596071 is a reply to message #377469] |
Wed, 09 May 2007 04:59  |
| Eclipse User |
|
|
|
This is a self reply.
> Either I found a bug or I am doing something wrong.
I found that this is a bug.
> Now, if I test those two parts of the grammar (by setting Expression or
> LogicalExpression as the main template) the parsing goes well. However, if
> I have a non-ambiguous rule producing either an Expression or a
> LogicalExpression, in both cases there are problems parsing the
> expression.
The ANTLR .g file produced by TCS contains a rule for each operator priority
level. The rule priority_0 is the one producing primary non-terminals. The
problem is that those rules are shared (same name) between different
operatored expressions.
Maybe TCS should prefix the rules with the expression non-terminal name
(e.g. Expr_priority_0 and LogicalExpr_priority_0) or just forbid the
declaration of multiple "operatored" expressions.
As a temporary workaround I implemented one of the two expression types
without using shortcut operator rules (the good old way, using recursive
rules). It isn't good for the KM3 metamodel (I had to define "useless"
classes), but I don't see any other solution, except fixing the .g file by
hand.
--
Lorenzo
|
|
|
| Re: [TCS] Multiple "operatored" templates conflict [message #596073 is a reply to message #377471] |
Wed, 09 May 2007 11:31 |
| Eclipse User |
|
|
|
Hello,
>> Either I found a bug or I am doing something wrong.
>
> I found that this is a bug.
Actually it is more a missing feature than a bug.
Or, the bug is that TCS2Problem.atl does not detect that you illegally
try to have two expression hierarchies, which is not supported by the
current version of TCS.
In order to have several expression hierarchies, you would need several
lists of operator priorities.
That being said, this feature is definitely in my TODO list. I should
probably take the time to put this list on the wiki before you have
rediscovered it on your own ;-).
A possible workaround would be to have only one expression hierarchy by
merging both. This would work if no ambiguity results from the merging.
The only drawback would then be that your parser would accept some
illegal programs. However, you can still detect these after parsing
using a simple MM2Problem.atl checking transformation.
Regards,
Frédéric Jouault
|
|
|
| Re: [TCS] Multiple "operatored" templates conflict [message #596087 is a reply to message #377473] |
Wed, 09 May 2007 13:52 |
| Eclipse User |
|
|
|
> That being said, this feature is definitely in my TODO list. I should
> probably take the time to put this list on the wiki before you have
> rediscovered it on your own ;-).
:)
> A possible workaround would be to have only one expression hierarchy by
> merging both. This would work if no ambiguity results from the merging.
I had that idea too, but it is not applicable because of ambiguity between
primaries of the two hierarchies.
For the time being I will probably stick with the traditional "unmanaged"
way for the simplier expression type.
Thank you again.
--
Lorenzo
|
|
|
| Re: [TCS] Multiple "operatored" templates conflict [message #608061 is a reply to message #377475] |
Sat, 06 October 2007 16:22 |
| Eclipse User |
|
|
|
Hello,
The new version of TCS supports multiple operator tables ;-).
For a usage example, have a look at the LOTOS syntax in the TCS zoo:
http://wiki.eclipse.org/TCS/Zoo
Please, let us know if it works for you.
Best regards,
Frédéric Jouault
Lorenzo Dalla Vecchia wrote:
>> That being said, this feature is definitely in my TODO list. I should
>> probably take the time to put this list on the wiki before you have
>> rediscovered it on your own ;-).
>
> :)
>
>> A possible workaround would be to have only one expression hierarchy
>> by merging both. This would work if no ambiguity results from the
>> merging.
>
> I had that idea too, but it is not applicable because of ambiguity
> between primaries of the two hierarchies.
>
> For the time being I will probably stick with the traditional
> "unmanaged" way for the simplier expression type.
> Thank you again.
>
> --
> Lorenzo
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.06653 seconds
Home