| [TCS] Operators [message #4149] |
Wed, 27 February 2008 08:12  |
Eclipse User |
|
|
|
Hi,
I struggle a lot with how TCS defines Operators. I found out through trial
and error that i.e. priorities in OperatorLists always have to start with
0 and increase by 1, that just saying operatored in a ClassTemplate means
implicitly that the anonymous OperatorList will be used, things like that.
Is there any documentation about TCS somewhere where such things would be
explained?
Is there any way planned to make such constraints as above explicit
somewhere so that i.e. Injector generation fails with a meaningful error
message?
|
|
|
|
| Re: [TCS] Operators [message #4848 is a reply to message #4217] |
Tue, 11 March 2008 10:26  |
| Eclipse User |
|
|
|
Hello,
> I struggle a lot with how TCS defines Operators. I found out through
> trial and error that i.e. priorities in OperatorLists always have to
> start with 0 and increase by 1, that just saying operatored in a
> ClassTemplate means implicitly that the anonymous OperatorList will be
> used, things like that.
> Is there any documentation about TCS somewhere where such things would
> be explained?
We are working on the documentation. In the mean time, you can look at
the TCS Zoo for examples (e.g., the LOTOS language uses advanced
operator features).
> Is there any way planned to make such constraints as above explicit
> somewhere so that i.e. Injector generation fails with a meaningful error
> message?
Yes, it is planned.
We are going to release a new version of the TCS constraints checker
that checks for more problems. Additionally, we can also accept bugzilla
entries for test cases presenting problems that should be detected.
> could two different operatored ClassTemplates (not extending each other
> or a common superclass) ever share the same OperatorList?
Operator support in TCS basically corresponds to the need for left
recursion. In the case that you describe, you would not have
left-recursion in one of the case, would you?
When there is no left-recursion problem, you should not need to add the
operator to the table. That being said, we are of course interested by a
counterexample.
> I see that for me, the Grammar generation works, and the parser
> compiles, but the generated grammar only mentions one of the
> classtemplates in production rule
> priority_0 when 2 ClassTemplates are operatored (without named
> operatorList)
> I guess this would be an error in the TCS definition, so it should be
> forbidden to attempt so.
You are correct.
Best regards,
Frédéric Jouault
|
|
|
Powered by
FUDForum. Page generated in 0.03458 seconds
Home