|
|
Re: XText for existing language [message #1021969 is a reply to message #1021941] |
Thu, 21 March 2013 02:29 |
Henrik Lindberg Messages: 2509 Registered: July 2009 |
Senior Member |
|
|
On 2013-21-03 1:28, Steve Kallestad wrote:
> There's no reason not to give it a shot. Defining the grammar is
> relatively easy once you get going.
> I gather that there are a few idiosyncrasies to deal with when things
> get more complex than what I deal with, but from where I'm standing the
> basics of defining syntax highlighting is pretty straightforward.
>
> I've seen the recommendation a few times to avoid trying to handle
> everything with grammar and it makes sense. The grammar defines your
> tokenizer and basic model description.
> My advice is spend three days learning, googling, and trying it out. If
> you're happy with your progress, keep moving forward. If not, there are
> alternatives.
> I hadn't used the term AST since college and was completely ignorant of
> EMF, but in the last two weeks I've managed to come up with something
> that I'm very impressed with so far. There were easier roads to go
> down, but the end results from XText are very open to further
> customization and opened up my eyes to a lot of possibilities.
>
>
Start with the terminals of your language.
Write the smallest possible grammar to test your terminals.
Try to stick with just the terminals defined by Xtext standard - have
very good reasons to not use them. (This to avoid creating overlapping
terminals, as well as not benefiting from pre-configured support from Xtext.
Continue in small steps. A one rule at a time, or a very small set.
This prevents you from getting hundreds of lines of errors/warnings and
gobbledygook as a result. When you proceed in a stepwise fashion you
know which construct caused things to blow up.
Let Xtext generate the model for you until you are satisfied with your
grammar - at that point switch to an external model (to prevent
accidental generation of an unsatisfactory model.
Read through the Xtext documentation, familiarize yourself with the
concepts.
If you do not already know EMF - read up on that too.
Read the Google Guice documentation.
Have fun.
Regards
- henrik
|
|
|
|
Re: XText for existing language [message #1022346 is a reply to message #1021969] |
Thu, 21 March 2013 17:59 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi
Henrik's steps are very sensible.
However you might do well to start with some tutorials to avoid being
biased by 'the old way'.
Xtext is very powerful and you should work with it rather than against
it. As with any powerful
tool you will find that revisiting your early attempts once you have
gained experuence is a bit
embarassing. Expect to make early mistakes.
I migrated OCL from an LALR LPG grammar to Xtext quite quickly, but my
first 'finished' attempt
was about ten times slower because I forced Xtext to work in an
LALR-fashion that wsan't appropriate
When I revisited my approach to work in an LL with EBNF way, the speed
difference fell to two-fold
which is getting close to my instrumentation uncertainties.
Xtext's ability to resolve proxies in the grammar is incredibly powerful
and you need to learn to
use it to advantage. The way you do things at the moment is almost
certainly inferior by
comparison and will benefit from changing.
Regards
Ed Willink
On 21/03/2013 02:29, Henrik Lindberg wrote:
> On 2013-21-03 1:28, Steve Kallestad wrote:
>> There's no reason not to give it a shot. Defining the grammar is
>> relatively easy once you get going.
>> I gather that there are a few idiosyncrasies to deal with when things
>> get more complex than what I deal with, but from where I'm standing the
>> basics of defining syntax highlighting is pretty straightforward.
>>
>> I've seen the recommendation a few times to avoid trying to handle
>> everything with grammar and it makes sense. The grammar defines your
>> tokenizer and basic model description.
>> My advice is spend three days learning, googling, and trying it out. If
>> you're happy with your progress, keep moving forward. If not, there are
>> alternatives.
>> I hadn't used the term AST since college and was completely ignorant of
>> EMF, but in the last two weeks I've managed to come up with something
>> that I'm very impressed with so far. There were easier roads to go
>> down, but the end results from XText are very open to further
>> customization and opened up my eyes to a lot of possibilities.
>>
>>
>
> Start with the terminals of your language.
> Write the smallest possible grammar to test your terminals.
> Try to stick with just the terminals defined by Xtext standard - have
> very good reasons to not use them. (This to avoid creating overlapping
> terminals, as well as not benefiting from pre-configured support from
> Xtext.
>
> Continue in small steps. A one rule at a time, or a very small set.
> This prevents you from getting hundreds of lines of errors/warnings
> and gobbledygook as a result. When you proceed in a stepwise fashion
> you know which construct caused things to blow up.
>
> Let Xtext generate the model for you until you are satisfied with your
> grammar - at that point switch to an external model (to prevent
> accidental generation of an unsatisfactory model.
>
> Read through the Xtext documentation, familiarize yourself with the
> concepts.
> If you do not already know EMF - read up on that too.
> Read the Google Guice documentation.
>
> Have fun.
>
> Regards
> - henrik
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.02866 seconds