Home » Modeling » TMF (Xtext) » Terminals vs Datatypes vs Rules
| Terminals vs Datatypes vs Rules [message #806191] |
Fri, 24 February 2012 17:18  |
 Alex G
Messages: 96
Registered: January 2012 |
Member |
|
|
Hi!
I want to be able to specify labels of the following kind:
- default = ID (without the "^" escape at the beginning)
- indexed = default '[' (INT ',' INT*) ']'
- other = '<' default '>'
- yetanother = '<' indexed '>'
The question is, what is the "best way" in order be able to specify these elements? I want to be able to reference these guys, s.t. I will need a value converter or a qualified name provider.
For "default" I would overwrite the ID from Terminals.xtext:
terminal ID: ('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'_'|'0'..'9')*;
Since I want to allow some hidden whitespaces and context in "indexed" the choice here is a data type
Indexed: ID '[' INT (', ' INT)* ']'
If I would define Indexed as
Indexed: ID '[' INT (', ' INT)* ']'
MaybeIndexed: ID | Indexed;
then there will hopefully be no ambiguities, if I take "ID" and "Indexed" for references.
For the case I want to reference not only to the name of the array, but also the items, I would have to use then a parser rule
Indexed: idname=ID '[' dims+=INT (', ' dims+=INT)* ']'
together with a qualified name provider that computes the name out of idname and dims. But then I will not be able to use "Indexed" as an EString for reference. Can I somehow make it a data type?
Furhtermore I want to be able to parametrize the dimensions:
Parameter: INT | ID
Indexed: ID '[' Parameter (', ' Parameter)* ']'
In this case I want to compute the full name only for INT parameters, for example:
bla[2 ,5 /*comment*/, 7 ] ==> "bla[2,5,7]"
bla[2, n, 7] ==> "bla[2,*,7]"
The qualified name shall somehow consist of the String parts "bla[2," and ",7]", s.t. if I have another
bla[2, n, 7] somewhere in my model, then name uniqueness validation shall hold! Therefore I think I have to somehow overwrite some QualifiedNameComparator (is there one?) since I want to be able to reference symbolically by "bla[2,x,7]" (x instead of n) as well.
For the other and yetanother rules, I would appreciate to work with data types as well, if there will be again no ambiguities which rule to choose.
|
|
| |
| Re: Terminals vs Datatypes vs Rules [message #806420 is a reply to message #806191] |
Sat, 25 February 2012 00:05  |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Hi,
I suspect that you are missing one piece of the puzzle; the
QualifiedName datatype which is the result of parsing an ID.
You can have other data type value converters that convert other types
of information between your language textual representation and
Qualified Name. e.g.
IndexRef : ID '[' INT (',' INT)* ']' ;
Would have a type converted that produces something like:
ID.INT.INT
example:
a[1,2,3] becomes the Qualified Name a.1.2.3
Noone ever sees this (well sort of). How you choose to map things is up
to you.
You then include a mapping from this name to your instance in the
resource description - i.e. map the IndexedEntity below to export it
using the same mapping to QuaolifiedName.
IndexedEntity : id = ID (dim += INT (',' dim+= INT) ;
Your reference would then be expressed as:
SomethingWithARef : name = ID refToIndex = [IndexedEntity | IndexRef ];
Not sure I followed your reasoning at the end there, but you must
naturally be able to name and reference things without ambiguity - the
references are done using Type and Name, and you also have scoping that
makes values visible to the search performed by linking.
If none of the above will for you - I have more suggestions. In my
project the linking needs to be very flexible, I don't know if something
is a link or not, or what kind of link it is until I have done some
semantic analysis. For that purpose I do my own linking (I am still
using QualifiedNames and the same type or resource exports/imports). Can
tell you more if you need something like that.
I hope that helps.
Regards
- henrik
On 2012-24-02 18:18, Alex G wrote:
> Hi!
>
> I want to be able to specify labels of the following kind:
>
>
> default = ID (without the "^" escape at the beginning)
> indexed = default '[' (INT ',' INT*) ']'
> other = '<' default '>'
> yetanother = '<' indexed '>'
>
>
> The question is, what is the "best way" in order be able to specify
> these elements? I want to be able to reference these guys, s.t. I will
> need a value converter or a qualified name provider.
>
> For "default" I would overwrite the ID from Terminals.xtext:
>
> terminal ID: ('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'_'|'0'..'9')*;
>
> Since I want to allow some hidden whitespaces and context in "indexed"
> the choice here is a data type
>
> Indexed: ID '[' INT (', ' INT)* ']'
>
> If I would define Indexed as
>
> Indexed: ID '[' INT (', ' INT)* ']'
> MaybeIndexed: ID | Indexed;
>
> then there will hopefully be no ambiguities, if I take "ID" and
> "Indexed" for references.
> For the case I want to reference not only to the name of the array, but
> also the items, I would have to use then a parser rule
>
> Indexed: idname=ID '[' dims+=INT (', ' dims+=INT)* ']'
>
> together with a qualified name provider that computes the name out of
> idname and dims. But then I will not be able to use "Indexed" as an
> EString for reference. Can I somehow make it a data type?
>
> Furhtermore I want to be able to parametrize the dimensions:
>
> Parameter: INT | ID
> Indexed: ID '[' Parameter (', ' Parameter)* ']'
>
> In this case I want to compute the full name only for INT parameters,
> for example:
> bla[2 ,5 /*comment*/, 7 ] ==> "bla[2,5,7]"
> bla[2, n, 7] ==> "bla[2,*,7]"
>
> The qualified name shall somehow consist of the String parts "bla[2,"
> and ",7]", s.t. if I have another
> bla[2, n, 7] somewhere in my model, then name uniqueness validation
> shall hold! Therefore I think I have to somehow overwrite some
> QualifiedNameComparator (is there one?) since I want to be able to
> reference symbolically by "bla[2,x,7]" (x instead of n) as well.
>
> For the other and yetanother rules, I would appreciate to work with data
> types as well, if there will be again no ambiguities which rule to choose.
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 21:11:54 GMT 2024
Powered by FUDForum. Page generated in 0.03269 seconds |
] 
Search
Help
Register
Login
Home
