|
|
|
|
Re: Parsing a grammar that allows for conditional compilation [message #733527 is a reply to message #732223] |
Wed, 05 October 2011 00:04 |
Henrik Lindberg Messages: 2509 Registered: July 2009 |
Senior Member |
|
|
Start by reading up on how linking and scoping works as this enables you
to ask more specific questions.
For starters you need an evaluator to be able to handle the
if(this || that) style of preprocessor directives.
Since the preprocessor directives may not follow the normal scoping
rules of the language, you may need to solve it by:
- have the resource descriptions include information about the
conditional scopes as a data element on the exported IEObjectDescription
- i.e. "coloring" expressions with their environmental applicability.
- modify linking to make use of this information (i.e. determine
"applicable colors" for the "link tail" and use that to filter the
visible exports when determining the "link head").
An alternative solution is to involve the colors in naming (you can
probably use more magic out of the Xtext box that way), but it could
explode with permutations and get messy (not knowing how advanced you
need this to be). I.e. export a "foo" in all namespaces, and have colors
as global name spaces. php.foo, js.foo, etc. you need one namespace for
"transparent" as well. Then it is a matter of arrange scopes in a
hierarchy "global transparent" > more specific > even more specific etc.
The complication here is to deal with both the normal scoping of the
language and the coloring at the same time.
I hope my rambling on the topic is of some help...
Regards
- henrik
On 10/4/11 11:35 AM, eecolor wrote:
> Yes, you are right, I am working on a grammar for haXe (although I am
> not sure if I ever will get it done). I understand what you are saying,
> but what you suggest is more suited for a compiler. In an editor you are
> essentially working with possibilities, within the editor it's all about
> scope. The preprocessor directives determine the scope in which elements
> are usable.
>
> If an element is marked as being php only, it can only reach elements
> that are available in the php scope; Variables can have the same name as
> long as they are in a different scope.
>
> What I am looking for in this topic is suggestions as to where in xText
> I would need to look to make changes to get the desired behavior.
>
> Thanks for the input!
|
|
|
|
Re: Parsing a grammar that allows for conditional compilation [message #733666 is a reply to message #733591] |
Wed, 05 October 2011 10:56 |
Henrik Lindberg Messages: 2509 Registered: July 2009 |
Senior Member |
|
|
I think this can be build by using an external lexer equipped with a
special preprocessing step that evaluates the macros and figures out
which sections of the text that should be "filtered out". When lexing
these sections are returned as token PREPROCESSOR.
In the grammar PREPROCESSOR is marked as hidden.
It is not possible to simply filter things out (i.e. let the
lexer/grammar only see the text that passed the filter) since a save of
the text would then remove all that was filtered out (just to mention
one of the things that will be screwed up).
Remaining work is to deal with the coloring of the PREPROCESSOR tokens -
coloring the code inside the preprocessor section could be difficult if
it based on semantics - marking keywords should be easy though. You may
want some special coloring of the macro keywords e.g. #if.
In your linker (afterLinking) you can perform validation of your
PREPROCESSOR segments.
- henrik
On 10/5/11 9:07 AM, Daniel wrote:
> eecolor wrote on Tue, 04 October 2011 11:35
>> I understand what you are saying, but what you suggest is more suited
>> for a compiler. In an editor you are essentially working with
>> possibilities, within the editor it's all about scope.
>
>
> That's true it's the compilers part, but Xtext isn't an "editor only"
> framework. If you implement the required stuff for haXe (grammar,
> scoping, validation etc.) you already have reinvent haXe. You'd have a
> ready to use EMF model for code generation and created your own
> programming language with the syntax of haXe.
> Some time ago I started a Xtext project for haXe too and came to the
> solution I would create my own language if I continue. I had problems to
> implement all the scoping so I stopped my project till I have more time.
> Back to your problem:
> You can do everything using preprocessor, they are not limited to any
> declarations. Something like this would be valid:
>
>
> #if php
> class
> #else interface
> #endif
>
> #if js
> JsContext
> #elseif php
> PhpContext
> #else
> $ I Am Invalid Code &%
> #end
>
>
> According to your flags set the other code is kicked out and simply
> ignored. Therefore you have to implement the different target platforms
> before the code parsing starts and continue work on the preprocessed code.
> Not all keywords and other rules get their own property within the EMF
> Model. There's no (clean, easy and simple) way make all language
> elements conditional. I'd definitly recommend you to implement a simple
> preprocessor which will filter your source-code beforehand and you'll be
> fine. ;)
>
>
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.01977 seconds