|
|
Re: [TCS] Operators [message #4848 is a reply to message #4217] |
Tue, 11 March 2008 14:26 |
Frédéric Jouault Messages: 572 Registered: July 2009 |
Senior Member |
|
|
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.03368 seconds