|
|
|
|
Re: [Xtext] Grammar - Enhancing the infered model for language expressions [message #661294 is a reply to message #661023] |
Thu, 24 March 2011 01:03   |
Sebastian Zarnekow Messages: 3116 Registered: July 2009 |
Senior Member |
|
|
Hi,
use the following and a value converter instead:
Add returns MyModel::Operator : '+' ;
Mul returns MyModel::Operator : '*' ;
See the docs for details on the IValueConverter.
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 22.03.11 19:14, schrieb Henrik Lindberg:
> On 3/22/11 6:44 PM, Didier Villevalois wrote:
>> Henrik Lindberg wrote on Tue, 22 March 2011 09:45
>>> At some point you most likely want to shift to an external model
>>> instead of generating it from the grammar. Using an imported model
>>> gives you full control.
>>
>>
>> OK I understand that maintaining my own model would enable me to have
>> the needed type hierarchy and have features at the needed level in this
>> hierarchy.
>>
>> However, I think I still can't use values from the same enum in
>> different parser rules. Am I wrong ?
>>
>
> Yes, but you need two different rules - both returning the same Enum
> type. Something like:
>
> Add returns MyModel::Operator : op = '+' ;
> Mul returns MyModel::Operator : op = '*' ;
>
> or somesuch... But I don't know how well that works with the Xtext
> grammar, if it needs to understand that it is an Enum or not. I ran into
> some issues when using Enums in Eclipse b3, and ended up writing some
> helpers (enum data type). For operators I used strings (and validation).
> I know that others use references/links for the same thing.
>
> - henrik
|
|
|
Re: [Xtext] Grammar - Enhancing the infered model for language expressions [message #1847761 is a reply to message #661294] |
Sat, 06 November 2021 05:05  |
Mirko Raner Messages: 124 Registered: July 2009 Location: New York City, NY |
Senior Member |
|
|
Has anyone found a solution to OP's question #3 in the meantime? (i.e., pulling up common features in an expression grammar)
I struggle with a very similar issue right now. My grammar contains an expression grammar like this:
Expression: Partition;
Partition returns Expression:
Qualification ({Partition.dispatchObject=current} '??' => cases += ClosureWithParameters+)*;
Qualification returns Expression:
Disjunction ({Qualification.left=current} operator=QualificationOperator right=Qualification)?;
Disjunction returns Expression:
Conjunction ({Disjunction.left=current} operator=DisjunctionOperator right=Conjunction)*;
// ... about 10 to 15 additional productions with the same left/operator/right structure...
Exponentiation returns Expression:
Prefixation ({Exponentiation.left=current} operator=ExponentiationOperator right=Prefixation)*;
Prefixation returns Expression:
{Prefixation}
operator=(PrefixOperator|PlusAdditionOperator|MinusAdditionOperator|PlusMinusAdditionOperator|MinusPlusAdditionOperator)
operand=Prefixation | Invocation;
Invocation returns Expression:
Primary
(=>({Navigation.object=current} '.'? member=[MethodDeclaration])
|=>({Invocation.target=current} arguments=Arguments))*;
In other words, most, but not all, of the expression grammar productions have a left/operator/right structure. I tried to extract common features into its own type by adding a production like this:
BinaryOperation: Qualification | Disjunction | ... | Exponentation;
This produces the desired hierarchy structure but does not pull up the left/right or operator features (BinaryOperation has no features of its own at all).
As a result, I have a significant amount of code duplication in the scoping, validation, and code generation areas of my code. For example, even though the code generation is identical for all binary operators, I have 15 or 20 similar methods that extract left/operator/right and pass it to a common method. I'd really like to get rid of these redundant methods as well as similar sets of methods in several other areas.
Is there a way in Xtext today to extract common features of types that appear in an expression grammar?
|
|
|
Powered by
FUDForum. Page generated in 0.02240 seconds