Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » #include-like feature?(Preprocessor-like #include construct)
#include-like feature? [message #654018] Sun, 13 February 2011 00:03 Go to next message
Olivier Parisy is currently offline Olivier ParisyFriend
Messages: 1
Registered: February 2011
Junior Member
How would you go about adding to an Xtext DSL a construct similar to #include in C/C++ or include in PHP?

It would not be defined as an importation in the local scope of symbols parsed in another input, but would actually behave as if the included input was textually inserted at the #include location.

In this way, the included input would be parsed with respect to the context in which it appears in the including input. Hence the included input may not be parseable as a standalone file by the DSL.

As an illustration, let us consider a DSL composed of functions signatures and body, those bodies being composed of statements. Only signatures are accepted as top-level elements by the grammar.

An input "A" could then be composed of:
function xx(a,b):
  statement1
  #include "B"
  statement4

And the "B" input would be composed of:
  statement2
  statement3

Here note that B cannot be parsed by the DSL; it is only meaningful in the context of its inclusion in A.

How can such a construct be implemented in an Xtext parser?

Regards,
Olivier.


[Updated on: Sun, 13 February 2011 00:04]

Report message to a moderator

Re: #include-like feature? [message #654022 is a reply to message #654018] Sun, 13 February 2011 02:14 Go to previous message
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2509
Registered: July 2009
Senior Member
This has been discussed earlier in this forum - you may want to search
for some other replies - but here is my understanding of what would be
needed.

1. The lexer needs to be made aware of "includes" and provide the
reading of these (naive implementation would just "multiplex the input
stream).

2. The problem is now that the grammar sees the included tokens as being
part of the original token stream and will include the text in the editor.

3. Implement a mechanism to hide the included text and instead show the
include (could perhaps be done with something like folding).

4. Implement a mechanism to prevent the user from editing the included text.

5. You want the user to expand the included text to make it possible to
have error markers in the text (they may be different for different
inclusions of the same file).

6. You need to implement a mechanism to keep the linenumbers sane - the
included text needs to be in the token stream to allow parsing, but you
do not want the line numbers in the file doing the inclusion to change
(in all error reports etc.). And you need to associate an error with
something like "error at line 1 in file xyz.xx included at line 10 in
file abc.xx, included at line 47 in file foo.xx - ad nauseum...), this
since includes could probably be nested (if you are following the
C-language model). Oh, and guard against circular includes.

7. You need to set up listening if one of the included files change.
(i.e. the entire chain of includes... again guard against circularity).

?. Probably lots more to do...

n. Reconsider if you really really want to support includes ;)


Regards
- henrik

On 2/13/11 1:03 AM, Olivier Parisy wrote:
> How would you go about adding to an Xtext DSL a construct similar to
> #include in C/C++ or include in PHP?
>
> It would not be defined as an importation in the local scope of symbols
> parsed in another input, but would actually behave as if the included
> input was textually inserted at the "#include" location.
>
> In this way, the included input would be parsed with respect to the
> context in which it appears in the including input. Hence the included
> input may not be parseable as a standalone file by the DSL.
>
> As an illustration, let us consider a DSL composed of functions
> signatures and body, those bodies being composed of statements. Only
> signatures are accepted as top-level elements by the grammar.
>
> An input "A" could then be composed of:
> function xx(a,b):
> statement1
> #include "B"
> statement4
> And the "B" input would be composed of:
> statement2
> statement3
> Here note that B cannot be parsed by the DSL; it is only meaningful in
> the context of its inclusion in A.
>
> How can such a construct be implemented in an Xtext parser?
>
> Regards,
> Olivier.
>
>
>
Previous Topic:PROBLEMS WITH XTEXT CODE GENERATION
Next Topic:Boolean expressions grammar
Goto Forum:
  


Current Time: Fri Mar 29 06:22:51 GMT 2024

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

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

Back to the top