Community
Participate
Working Groups
Splitting grammars into several files would simplify the development and maintenance of large grammars (several thousand LOC) especially when more than one person is involved. The current grammar mixin mechanism is too heavy, means requires typically own projects or at least own workflows. I'm thinking about a leaner mechanism where several .xtext files within a Xtext project make up the whole grammar and each .xtext file could bee seen as a Xtext fragment. - Something like that.
(In reply to comment #0) > Splitting grammars into several files would simplify the development and > maintenance of large grammars (several thousand LOC) especially when more than > one person is involved. > > The current grammar mixin mechanism is too heavy, means requires typically own > projects or at least own workflows. No, there is no requirement for a grammar to have its own project. It works perfectly fine to have multiple grammars in the same project. They can also share the Ecore model, if this seems useful. And no, they don't need their own mwe2-worklfow as well, since you can put multiple Generator-Components in the same workflow file. Just make sure that languages are generated in the order in which they depend on each other. > I'm thinking about a leaner mechanism where several .xtext files within a Xtext > project make up the whole grammar and each .xtext file could bee seen as a > Xtext fragment. - Something like that. Two points on that... - please be aware that if one grammar only has cross references to model elements from a second grammar, these grammars can already exist independently. They depend on each other on the Ecore-level, but not on the grammar level. - even if there would be a mechanism to distribute the grammar rule of one language over multiple files, they would probably still lead to the same parser. The consequence is that there can only be one Generator component (i.e. one mwe2-workflow) that takes care of all of them.
>even if there would be a mechanism to distribute the grammar rule of one >language over multiple files, they would probably still lead to the same >parser. The consequence is that there can only be one Generator component (i.e. >one mwe2-workflow) that takes care of all of them. That's ok for me. Maybe I should explain why I'd like to have an additional splitting mechanism. I'm currently working on a project to define the grammar of Oracle PL/SQL. But unfortunately plain PL/SQL files do not exist. In fact, PL/SQL comes typically in SQL*Plus files including SQL*Plus commands like REM, PROMPT and similar. SQL*Plus is a language of its own and processes statements of the following languages: + SQL*Plus | -+ SQL | | -+ Data Definition Language (DDL) | | | -+ PL/SQL | | | -+ Java | | -+ Data Manipulation Language (DML) | | -+ Transaction Control Statements | | -+ Session Control Statements | | -+ System Control Statements | -+ PL/SQL | | -+ Data Manipulation Language (DML) | | -+ Transaction Control Statements On one hand DDL uses PL/SQL e.g. for triggers, packages, types. On the other hand PL/SQL uses DML and Transaction Control Statements. - Organizing Xtext files in terms of grammar or languages, avoiding interdependencies lead to a few very large .xtext files. Therefore we thought about splitting the large .xtext files into smaller chunks. E.g. a single file for the "alter database" statement which has currently over 300 LOC. I hope the idea of the enhancement request is clearer now.
Thanks for providing a real-world use case for multiple grammar mixins. I close this and add a link to https://bugs.eclipse.org/bugs/show_bug.cgi?id=256403 in order to further discuss whether this is one feature or two distinct. *** This bug has been marked as a duplicate of bug 256403 ***
