|
| Re: Modularisation of a big grammar [message #682066 is a reply to message #682054] |
Fri, 10 June 2011 10:29   |
 Alexander Nittka
Messages: 1193
Registered: July 2009 |
Senior Member |
|
|
Hi,
Xtext does not have an include mechanism in the sense that you include a bunch of Xtext-grammars. It allows only single grammar inheritance (first line grammar ... with superGrammar). However superGrammar is not only the xtext file but the entire language infrastructure. This is why it is not merely a splitting up of the grammar file (and I wouldn't do it if I was not really forced to; note also that you don't really want the complete infrastructure - e.g. Editor - for the SubConfigs).
The basic layout would be SC1-Grammar extends Default-Terminals, SC2 extends SC1, SC3 extends SC2 and Config extends SC3, so if there are "cyclic dependencies" among the configs, splitting them up might not even be possible (not sure).
as to 1) Basically it is possible. You can create separate projects (relatively simple) or have them in the same project (bit more complicated, as you have get the workflow right, haveing more than one language definition in the generator component).
as to 2) Look at the generator fragments in the workflow, there is one responsible for meta model generation.
as to 3) The grammar rules are made accessible via the "with" in the grammar header, if you reference Types, you have to import the metamodel via import (and configure the generator fragment, such that the types are not generated again)
Summary: don't do it, you will spend days until you will have the generator-Infrastructure working.
Alex
P.S.: I've never looked into the possibility, but it might be a cleaner solution to have different xtext-grammars and have a (custom-self-implemented) preprocessing step that copies the rules into a combined grammar and uses that one. This is not without problems, e.g. if you have cross references to types that are not defined in the current file.
Need training, onsite consulting or any other kind of help for Xtext?
Go visit http://xtext.itemis.com or send a mail to xtext@itemis.de
|
|
|
| Re: Modularisation of a big grammar [message #682073 is a reply to message #682066] |
Fri, 10 June 2011 10:47 |
Ed Willink
Messages: 7670
Registered: July 2009 |
Senior Member |
|
|
Hi
I wouldn't be quite so negative.
Cyclic dependencies can be resolved by a dummy rule (analoguous to an
abstract function in Java). This highlights that you don't get true
modularity. All rules names are in the one namespace so an including
grammar overrides colliding names in the included grammar.
Perhaps you would be better to write smaller modular grammars and use a
simple script to strip preamble and stubs from each grammar module and
then concatenate the results following an appropriate overall preamble.
There is not much point in creating the fully tooled intermediates since
they just fill up disk space and the ANTLR Java files are BIG. For OCL I
use intermediates because OCL is re-used in different ways, but the
consequences on 'code' sizes are unpleasant.
Regards
Ed Willink
On 10/06/2011 11:29, Alexander Nittka wrote:
> Hi,
>
> Xtext does not have an include mechanism in the sense that you include
> a bunch of Xtext-grammars. It allows only single grammar inheritance
> (first line grammar ... with superGrammar). However superGrammar is
> not only the xtext file but the entire language infrastructure. This
> is why it is not merely a splitting up of the grammar file (and I
> wouldn't do it if I was not really forced to; note also that you don't
> really want the complete infrastructure - e.g. Editor - for the
> SubConfigs).
>
> The basic layout would be SC1-Grammar extends Default-Terminals, SC2
> extends SC1, SC3 extends SC2 and Config extends SC3, so if there are
> "cyclic dependencies" among the configs, splitting them up might not
> even be possible (not sure).
>
>
> as to 1) Basically it is possible. You can create separate projects
> (relatively simple) or have them in the same project (bit more
> complicated, as you have get the workflow right, haveing more than one
> language definition in the generator component).
>
> as to 2) Look at the generator fragments in the workflow, there is one
> responsible for meta model generation.
>
> as to 3) The grammar rules are made accessible via the "with" in the
> grammar header, if you reference Types, you have to import the
> metamodel via import (and configure the generator fragment, such that
> the types are not generated again)
>
> Summary: don't do it, you will spend days until you will have the
> generator-Infrastructure working.
>
> Alex
>
> P.S.: I've never looked into the possibility, but it might be a
> cleaner solution to have different xtext-grammars and have a
> (custom-self-implemented) preprocessing step that copies the rules
> into a combined grammar and uses that one. This is not without
> problems, e.g. if you have cross references to types that are not
> defined in the current file.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03926 seconds
] 
Search
Help
Register
Login
Home
