|
| Re: Common Terminal-Grammar generates Compile-Errors [message #1271000 is a reply to message #1270606] |
Thu, 13 March 2014 22:30   |
Eclipse User |
|
|
|
Hi, (in addition to the loading problem), your new terminals
has problems of their own...
You may have to turn on backtracking in the lexer (not a good idea) to
make it differentiate between a COMPONENT_ID and an OTHER_ID.
Your OTHER_ID is speciied to also accept "nothing" (* is 0 or more), you
probably wanted:
OTHER_ID : ('A'..'Z')|'_' ;
(if this is for a single char)
In practice, you may be far better off by having a permissive terminal
and then validate (this unless your grammar depends on if it is a single
character ID or not).
IIRC correctly, the standard ID also allows upper case letters, and if
so you also have overlapping terminals and just opened a can of worms...
what is AAABBBCCC ? three COMPONENT_ID?, one ID? or 9 OTHER_ID? What is
AAABbBCcC ? etc.
- henrik
On 2014-13-03 8:57, Marc Schlegel wrote:
> Hello everyone
>
> I am new to xText and I am currently running into a problem with my
> separate terminal-grammar.
>
> Currently I have to DSLs in separate projects where the second uses the
> first. So far so good. Now I needed special terminals and since I
> couldnt reference terminals which reside in the first project from my
> second project I duplicated them which gave me errors in my generation.
> Thus I thought to separate the terminal in a "common" grammar as it is
> done with org.eclipse.xtext.common.Terminals.
>
> So I came up with something like this.
> grammar mystuff.Terminals with org.eclipse.xtext.common.Terminals
>
> terminal COMPONENT_ID : ('A'..'Z')('A'..'Z')('A'..'Z'); // only 3
> upper-case-character
> terminal OTHER_ID : ('A'..'Z'|'_')*; // only upercase and underscore
>
> In my first DSL which is in the same package I am using this grammar
> grammar mystuff.MeldungsDsl with mystuff.Terminals
>
> generate meldungsDsl "http://www.mystuff/MeldungsDsl"
>
> ...rules using grammar just fine...
>
> When I run my workflow I get no errors but a lot of compile-errors
> afterwards. For example TerminalsStandaloneSetup cannot be resolved.
>
> So I guess I need to add something to my workflow, but I have no clue
> what is needed. When I am referencing another DSL with an Ecore I need
> to add this, but the terminal-grammar does not generate a separate
> Ecore...as far as I understand, since there is no generate keyword.
>
> Can someone help me out here about what is needed in the workflow? And
> what would I need to use the same terminal-grammar in my second project?
> Thanks
|
|
|
|
| Re: Common Terminal-Grammar generates Compile-Errors [message #1271717 is a reply to message #1271286] |
Sat, 15 March 2014 20:45 |
| Eclipse User |
|
|
|
On 2014-14-03 19:40, Marc Schlegel wrote:
> Thanks for the clarification.
>
> I think I will get back to just one grammar and be carefull about the
> terminal rules as you mentioned. I should get more into the
> language-definition before I break it up in multiple languages.
>
>
Rule of thumb: Implement the language in small iterations. Add as little
as possible at the time. Verify each step.
Start with only terminals and an extremely simple grammar. Test that the
terminals are lexed as you intend for a variety of input. If you don't
know that you got this right you will spend hours scratching your head
searching for what is wrong. Do all terminals of your language first
before you start with the real grammar. Have as few (and large)
terminals as possible.
Do not try to solve semantics with lexing, and avoid making the grammar
too strict as this makes for a bad user experience (every error ends up
being a syntax error).
Hope that helps.
- henrik
|
|
|
Powered by
FUDForum. Page generated in 0.06751 seconds
Home