|Re: Shift-reduce conflict between grammar rule and terminal in Xtext [message #902365 is a reply to message #902328]
||Fri, 17 August 2012 10:51
| Tu Do
Registered: August 2012
Alexander Nittka wrote on Fri, 17 August 2012 02:10|
keywords have a higher precedence than other terminals indeed, but only if they lead to a longer token. Your original CAT terminal definition included a white space, so "DOG 1234" was picked up by that terminal.
With your current ALPHA terminal rule you will have other problems. It conflicts with the default ID terminal which you import via "with ...Terminals".
"CAT ABC 12;" will not satisfy the CAT datatype rule.
It's true as you said. I got a conflict with terminal ID. However, with my solution, I can make DOG and CAT to be keywords, which are required. Further more, I need some rules which consist of one keyword and one alphabet character.
The approach suggested by Hendrick worked, but the keyword can't be highlighted.
|Re: Shift-reduce conflict between grammar rule and terminal in Xtext [message #902423 is a reply to message #902401]
||Fri, 17 August 2012 14:22
| Henrik Lindberg
Registered: July 2009
On 2012-17-08 15:24, Tu Do wrote:|
> Henrik Lindberg wrote on Fri, 17 August 2012 07:53
>> On 2012-17-08 12:51, Tu Do wrote:
>> > The approach suggested by Hendrick worked, but the keyword can't be
>> > highlighted.
>> You can highlight them as keywords using semantic highlighting.
>> - henrik
> So, other than the grammar rule, can we specify tokens which are not in
> the grammar to be keywords?
Out of the box you get a mapping from lexer tokens to highlighting
specs. And also out of the box all keywords are highlighted in the
You can customize this several ways.
The simplest is semantic highlighting which kicks in asynchronously. You
can then set/change the highlighting of anything (it is based on offsets
and lengths in the source text). (See PPSemanticHighlighter in
cloudsmith/geppetto @github for an example of semantic and textual
A more advanced way is to customize the lexer used for highlighting - it
does not have to have the same tokens etc. as the real grammar - but it
must naturally be matched with the specification in the highlighter.
The pros and cons are naturally that you get the token based lexer for
free and it provides very fast highlighting - the semantic one, since it
is asynchronous has a sometimes noticeable delay (first painted plain,
then as keyword, etc). With more work (customized highlighting lexer)
you may have difficulties expressing the rules if you need semantic
information + it is more work to write it.
> Also earlier you said that using value converter to check the lexed cat
> is a dog. Shouldn't this be the job of validtor? I think value converter
> is just for converting from object to object only.
That works too - depends on how you use the result. Say you assign a
boolean based on if you observed a DOG or not, and you have a rule that
accepts DOG, CAT, (and a bunch of other animals) as string, then you
have no model element to attach the check to. You would need a model
element representing DOG, that assigns the string to be able to validate
it with a check.
Hope that helps.
Powered by FUDForum
. Page generated in 0.01755 seconds