Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Common Terminal-Grammar generates Compile-Errors
Common Terminal-Grammar generates Compile-Errors [message #1270606] Thu, 13 March 2014 07:57 Go to next message
Marc Schlegel is currently offline Marc SchlegelFriend
Messages: 69
Registered: July 2009
Member
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.MyDsl with mystuff.Terminals

generate myDsl "http://www.mystuff/MyDsl"

...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

EDIT: I got the idea of creating a separate workflow for the terminal.xtext which I need to run prior to my first DSL. But now I get an error:
You may not generate an ANTLR parser for a grammar without production rules.
Sad

[Updated on: Thu, 13 March 2014 10:20]

Report message to a moderator

Re: Common Terminal-Grammar generates Compile-Errors [message #1271000 is a reply to message #1270606] Fri, 14 March 2014 02:30 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2509
Registered: July 2009
Senior Member
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 #1271286 is a reply to message #1271000] Fri, 14 March 2014 18:40 Go to previous messageGo to next message
Marc Schlegel is currently offline Marc SchlegelFriend
Messages: 69
Registered: July 2009
Member
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.

Re: Common Terminal-Grammar generates Compile-Errors [message #1271717 is a reply to message #1271286] Sun, 16 March 2014 00:45 Go to previous message
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2509
Registered: July 2009
Senior Member
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
Previous Topic:Validating string list items under a parent object.
Next Topic:Programmatically access elements imported from another Ecore model
Goto Forum:
  


Current Time: Thu Apr 25 19:17:05 GMT 2024

Powered by FUDForum. Page generated in 0.03412 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top