Home » Archived » GMT (Generative Modeling Technologies) » [TCS] multi-step reference resolution
|
Re: [TCS] multi-step reference resolution [message #380831 is a reply to message #380825] |
Mon, 07 January 2008 14:42 |
Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
Hi Andy,
TCS currently does not support this kind of reference resolution.
refersTo only allow to specify the attribute that will be used to
identify the referred element but it does not allow to specify this kind
of "namespace path".
Can you open a bug about this feature request? Thanks.
Best regards,
Mikael
Andy Carpenter wrote:
> We are trying to process an existing DSL that has a
> nested block structure but which allows references
> to objects in sibling blocks by specifying the path to
> the object, cf. referencing objects in Java packages.
> For example
>
> block0 {
> block1 {
> define v1;
> }
> block2 {
> define v2;
> v2 = block1.v1;
> }
> }
>
> Here, the reference to v1 in block2 has to use the
> prefix block1 to make the name v1 visible. Is there
> a variant of the referesTo operation that can be used
> to resolve such references, or is there a way to
> overload the implementation of referesTo to perform
> such resolution?
>
> Thanks for any help
> Andy.
>
>
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
|
Re: [TCS] multi-step reference resolution [message #380843 is a reply to message #380831] |
Wed, 09 January 2008 14:55 |
Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
To complete my previous answer. There may be a work around but you have
to change your metamodel (if you can). I suppose your metamodel is
something like this (in KM3):
class Block {
attribute name : String;
reference subblocks[*] ordered container : Block;
reference statements[*] ordered container : Statement;
}
abstract class Statement {}
class VariableDef extends Statement {
attribute varName : String;
}
class VariableRef {
reference varDef : VariableDef;
reference ownerblock[0-1] : Block; -- This to support the path to
sibling blocks
}
class Assignement extends Statement {
reference lhs : VariableRef;
reference rhs : VariableRef;
}
Then, your TCS should look like:
....
template Assignement
: lhs "=" rhs
;
template VariableRef
: (isDefined(ownerblock) ? ownerblock {refersTo = name} ".")
varDef{refersTo = varName, lookIn=ownerblock}
;
....
Hope this helps,
Mikael
Mikaël Barbero wrote:
> Hi Andy,
>
> TCS currently does not support this kind of reference resolution.
> refersTo only allow to specify the attribute that will be used to
> identify the referred element but it does not allow to specify this kind
> of "namespace path".
> Can you open a bug about this feature request? Thanks.
>
> Best regards,
> Mikael
>
> Andy Carpenter wrote:
>> We are trying to process an existing DSL that has a
>> nested block structure but which allows references
>> to objects in sibling blocks by specifying the path to
>> the object, cf. referencing objects in Java packages.
>> For example
>>
>> block0 {
>> block1 {
>> define v1;
>> }
>> block2 {
>> define v2;
>> v2 = block1.v1;
>> }
>> }
>>
>> Here, the reference to v1 in block2 has to use the
>> prefix block1 to make the name v1 visible. Is there
>> a variant of the referesTo operation that can be used
>> to resolve such references, or is there a way to
>> overload the implementation of referesTo to perform
>> such resolution?
>>
>> Thanks for any help
>> Andy.
>>
>>
>
>
>
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
|
Re: [TCS] multi-step reference resolution [message #380845 is a reply to message #380843] |
Wed, 09 January 2008 15:44 |
Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
I committed a sample project to illustrate this workaround (and
corrected some errors there are in my previous post). It is available
there:
http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt /org.eclipse.gmt.tcs/syntaxes/MSRT/
and also added a "samples langugages" section in the TCS Zoo:
http://wiki.eclipse.org/TCS/Zoo
Regards,
Mikael
Mikaël Barbero wrote:
> To complete my previous answer. There may be a work around but you have
> to change your metamodel (if you can). I suppose your metamodel is
> something like this (in KM3):
>
> class Block {
> attribute name : String;
> reference subblocks[*] ordered container : Block;
> reference statements[*] ordered container : Statement;
> }
>
> abstract class Statement {}
>
> class VariableDef extends Statement {
> attribute varName : String;
> }
>
> class VariableRef {
> reference varDef : VariableDef;
> reference ownerblock[0-1] : Block; -- This to support the path to
> sibling blocks
> }
>
> class Assignement extends Statement {
> reference lhs : VariableRef;
> reference rhs : VariableRef;
> }
>
> Then, your TCS should look like:
>
> ...
> template Assignement
> : lhs "=" rhs
> ;
>
> template VariableRef
> : (isDefined(ownerblock) ? ownerblock {refersTo = name} ".")
> varDef{refersTo = varName, lookIn=ownerblock}
> ;
> ...
>
> Hope this helps,
> Mikael
>
> Mikaël Barbero wrote:
>> Hi Andy,
>>
>> TCS currently does not support this kind of reference resolution.
>> refersTo only allow to specify the attribute that will be used to
>> identify the referred element but it does not allow to specify this
>> kind of "namespace path".
>> Can you open a bug about this feature request? Thanks.
>>
>> Best regards,
>> Mikael
>>
>> Andy Carpenter wrote:
>>> We are trying to process an existing DSL that has a
>>> nested block structure but which allows references
>>> to objects in sibling blocks by specifying the path to
>>> the object, cf. referencing objects in Java packages.
>>> For example
>>>
>>> block0 {
>>> block1 {
>>> define v1;
>>> }
>>> block2 {
>>> define v2;
>>> v2 = block1.v1;
>>> }
>>> }
>>>
>>> Here, the reference to v1 in block2 has to use the
>>> prefix block1 to make the name v1 visible. Is there
>>> a variant of the referesTo operation that can be used
>>> to resolve such references, or is there a way to
>>> overload the implementation of referesTo to perform
>>> such resolution?
>>>
>>> Thanks for any help
>>> Andy.
>>>
>>>
>>
>>
>>
>
>
>
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
| |
Re: [TCS] multi-step reference resolution [message #611111 is a reply to message #380825] |
Mon, 07 January 2008 14:42 |
Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
Hi Andy,
TCS currently does not support this kind of reference resolution.
refersTo only allow to specify the attribute that will be used to
identify the referred element but it does not allow to specify this kind
of "namespace path".
Can you open a bug about this feature request? Thanks.
Best regards,
Mikael
Andy Carpenter wrote:
> We are trying to process an existing DSL that has a
> nested block structure but which allows references
> to objects in sibling blocks by specifying the path to
> the object, cf. referencing objects in Java packages.
> For example
>
> block0 {
> block1 {
> define v1;
> }
> block2 {
> define v2;
> v2 = block1.v1;
> }
> }
>
> Here, the reference to v1 in block2 has to use the
> prefix block1 to make the name v1 visible. Is there
> a variant of the referesTo operation that can be used
> to resolve such references, or is there a way to
> overload the implementation of referesTo to perform
> such resolution?
>
> Thanks for any help
> Andy.
>
>
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
|
Re: [TCS] multi-step reference resolution [message #611160 is a reply to message #380831] |
Wed, 09 January 2008 14:55 |
Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
To complete my previous answer. There may be a work around but you have
to change your metamodel (if you can). I suppose your metamodel is
something like this (in KM3):
class Block {
attribute name : String;
reference subblocks[*] ordered container : Block;
reference statements[*] ordered container : Statement;
}
abstract class Statement {}
class VariableDef extends Statement {
attribute varName : String;
}
class VariableRef {
reference varDef : VariableDef;
reference ownerblock[0-1] : Block; -- This to support the path to
sibling blocks
}
class Assignement extends Statement {
reference lhs : VariableRef;
reference rhs : VariableRef;
}
Then, your TCS should look like:
....
template Assignement
: lhs "=" rhs
;
template VariableRef
: (isDefined(ownerblock) ? ownerblock {refersTo = name} ".")
varDef{refersTo = varName, lookIn=ownerblock}
;
....
Hope this helps,
Mikael
Mikaël Barbero wrote:
> Hi Andy,
>
> TCS currently does not support this kind of reference resolution.
> refersTo only allow to specify the attribute that will be used to
> identify the referred element but it does not allow to specify this kind
> of "namespace path".
> Can you open a bug about this feature request? Thanks.
>
> Best regards,
> Mikael
>
> Andy Carpenter wrote:
>> We are trying to process an existing DSL that has a
>> nested block structure but which allows references
>> to objects in sibling blocks by specifying the path to
>> the object, cf. referencing objects in Java packages.
>> For example
>>
>> block0 {
>> block1 {
>> define v1;
>> }
>> block2 {
>> define v2;
>> v2 = block1.v1;
>> }
>> }
>>
>> Here, the reference to v1 in block2 has to use the
>> prefix block1 to make the name v1 visible. Is there
>> a variant of the referesTo operation that can be used
>> to resolve such references, or is there a way to
>> overload the implementation of referesTo to perform
>> such resolution?
>>
>> Thanks for any help
>> Andy.
>>
>>
>
>
>
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
|
Re: [TCS] multi-step reference resolution [message #611162 is a reply to message #380843] |
Wed, 09 January 2008 15:44 |
Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
I committed a sample project to illustrate this workaround (and
corrected some errors there are in my previous post). It is available
there:
http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt /org.eclipse.gmt.tcs/syntaxes/MSRT/
and also added a "samples langugages" section in the TCS Zoo:
http://wiki.eclipse.org/TCS/Zoo
Regards,
Mikael
Mikaël Barbero wrote:
> To complete my previous answer. There may be a work around but you have
> to change your metamodel (if you can). I suppose your metamodel is
> something like this (in KM3):
>
> class Block {
> attribute name : String;
> reference subblocks[*] ordered container : Block;
> reference statements[*] ordered container : Statement;
> }
>
> abstract class Statement {}
>
> class VariableDef extends Statement {
> attribute varName : String;
> }
>
> class VariableRef {
> reference varDef : VariableDef;
> reference ownerblock[0-1] : Block; -- This to support the path to
> sibling blocks
> }
>
> class Assignement extends Statement {
> reference lhs : VariableRef;
> reference rhs : VariableRef;
> }
>
> Then, your TCS should look like:
>
> ...
> template Assignement
> : lhs "=" rhs
> ;
>
> template VariableRef
> : (isDefined(ownerblock) ? ownerblock {refersTo = name} ".")
> varDef{refersTo = varName, lookIn=ownerblock}
> ;
> ...
>
> Hope this helps,
> Mikael
>
> Mikaël Barbero wrote:
>> Hi Andy,
>>
>> TCS currently does not support this kind of reference resolution.
>> refersTo only allow to specify the attribute that will be used to
>> identify the referred element but it does not allow to specify this
>> kind of "namespace path".
>> Can you open a bug about this feature request? Thanks.
>>
>> Best regards,
>> Mikael
>>
>> Andy Carpenter wrote:
>>> We are trying to process an existing DSL that has a
>>> nested block structure but which allows references
>>> to objects in sibling blocks by specifying the path to
>>> the object, cf. referencing objects in Java packages.
>>> For example
>>>
>>> block0 {
>>> block1 {
>>> define v1;
>>> }
>>> block2 {
>>> define v2;
>>> v2 = block1.v1;
>>> }
>>> }
>>>
>>> Here, the reference to v1 in block2 has to use the
>>> prefix block1 to make the name v1 visible. Is there
>>> a variant of the referesTo operation that can be used
>>> to resolve such references, or is there a way to
>>> overload the implementation of referesTo to perform
>>> such resolution?
>>>
>>> Thanks for any help
>>> Andy.
>>>
>>>
>>
>>
>>
>
>
>
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 23:56:09 GMT 2024
Powered by FUDForum. Page generated in 0.03790 seconds
|