Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Concrete syntax vs desired model structure
Concrete syntax vs desired model structure [message #931719] Wed, 03 October 2012 13:10 Go to next message
Andrew Gacek is currently offline Andrew GacekFriend
Messages: 32
Registered: October 2011
Member
Suppose I have a language with function declarations like the following

f(x : int; y : bool)
g(x, y : int; z : bool; w : int)
h(x, y, z : bool; w : bool)


The point is, the parameters to a function may be grouped if they have the same type. I can use the following grammar to parse this:

FunDecl:
	name=ID '(' args+=VarGroup (';' args+=VarGroup)* ')' ';'
;

VarGroup:
	(vars+=Var (',' vars+=Var)*) ':' type=Type
;

Var: name=ID;

Type: 'int' | 'bool';


The downside is that the resulting model is somewhat annoying to work with since from a function declaration I can't immediately get a list of all its parameters. Instead I get a list of VarGroups and I have to extract the variables from each of those. Another pain is that given a variable, I need to navigate the model a bit in order to get its type. I would much prefer a model where a FunDecl has a list of variables, each of which has a type associated with it. Is there any way of structuring my grammar to achieve this (without modifying the concrete syntax)? I don't know if it's worth the trouble of using a custom Ecore model, but would that even solve this problem?

Thanks,
Andrew
Re: Concrete syntax vs desired model structure [message #931924 is a reply to message #931719] Wed, 03 October 2012 16:55 Go to previous messageGo to next message
Hallvard Traetteberg is currently offline Hallvard TraettebergFriend
Messages: 673
Registered: July 2009
Location: Trondheim, Norway
Senior Member
Andrew,

This is a general problem with DSLs: The envisioned concrete syntax is
often not close enough to the most convenient abstract syntax.

Sometimes you can bridge the gap by defining derived features, that
compute abstract syntax features from concrete syntax features. E.g. the
parameters feature of the Function class is derived from the varGroup
feature. So the parser fills the varGroup list and the derived feature's
getParameter method computes what's most convenient for the user of the
model.

There usually is a time trade-off that may be handled by caching lists
computed for derived features. If you set volatile to false, you get an
list field into which you can store the computed list.

Hallvard

On 03.10.12 06.10, Andrew Gacek wrote:
> Suppose I have a language with function declarations like the following
>
>
> f(x : int; y : bool)
> g(x, y : int; z : bool; w : int)
> h(x, y, z : bool; w : bool)
>
>
> The point is, the parameters to a function may be grouped if they have
> the same type. I can use the following grammar to parse this:
>
>
> FunDecl:
> name=ID '(' args+=VarGroup (';' args+=VarGroup)* ')' ';'
> ;
>
> VarGroup:
> (vars+=Var (',' vars+=Var)*) ':' type=Type
> ;
>
> Var: name=ID;
>
> Type: 'int' | 'bool';
>
>
> The downside is that the resulting model is somewhat annoying to work
> with since from a function declaration I can't immediately get a list of
> all its parameters. Instead I get a list of VarGroups and I have to
> extract the variables from each of those. Another pain is that given a
> variable, I need to navigate the model a bit in order to get its type. I
> would much prefer a model where a FunDecl has a list of variables, each
> of which has a type associated with it. Is there any way of structuring
> my grammar to achieve this (without modifying the concrete syntax)? I
> don't know if it's worth the trouble of using a custom Ecore model, but
> would that even solve this problem?
>
> Thanks,
> Andrew
Re: Concrete syntax vs desired model structure [message #932145 is a reply to message #931719] Wed, 03 October 2012 21:52 Go to previous message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
You can introduce a derived feature through extension methods in Xtend.

class FunDeclExtensions {
def static Iterable<Var> getVars(FunDecl it) {
args.map[vars].flatten
}
}

then you can use it like in this snippet ...

import static extension mypackage.FunDeclExtensions.*

def someCodeGeneration(FundDecl funDecl) '''
...
<<FOR var : funDecl.vars>>
...
<<ENDFOR>>
..
'''


Am 10/3/12 3:10 PM, schrieb Andrew Gacek:
> Suppose I have a language with function declarations like the following
>
>
> f(x : int; y : bool)
> g(x, y : int; z : bool; w : int)
> h(x, y, z : bool; w : bool)
>
>
> The point is, the parameters to a function may be grouped if they have
> the same type. I can use the following grammar to parse this:
>
>
> FunDecl:
> name=ID '(' args+=VarGroup (';' args+=VarGroup)* ')' ';'
> ;
>
> VarGroup:
> (vars+=Var (',' vars+=Var)*) ':' type=Type
> ;
>
> Var: name=ID;
>
> Type: 'int' | 'bool';
>
>
> The downside is that the resulting model is somewhat annoying to work
> with since from a function declaration I can't immediately get a list of
> all its parameters. Instead I get a list of VarGroups and I have to
> extract the variables from each of those. Another pain is that given a
> variable, I need to navigate the model a bit in order to get its type. I
> would much prefer a model where a FunDecl has a list of variables, each
> of which has a type associated with it. Is there any way of structuring
> my grammar to achieve this (without modifying the concrete syntax)? I
> don't know if it's worth the trouble of using a custom Ecore model, but
> would that even solve this problem?
>
> Thanks,
> Andrew


--
Need professional support for Xtext or other Eclipse Modeling technologies?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : http://blog.efftinge.de
Previous Topic:Detect extern model changes
Next Topic:problem for define my dsl
Goto Forum:
  


Current Time: Tue Apr 13 05:17:09 GMT 2021

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

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

Back to the top