#include-like feature? [message #654018] |
Sun, 13 February 2011 00:03 |
Olivier Parisy 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:
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 |
Henrik Lindberg 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.
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.01715 seconds