Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » GMT (Generative Modeling Technologies) » [TCS] multi-step reference resolution
[TCS] multi-step reference resolution [message #380825] Fri, 04 January 2008 13:50 Go to next message
Andy Carpenter is currently offline Andy CarpenterFriend
Messages: 145
Registered: July 2009
Senior Member
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.


--
-- ------------------------------------------------------------ -------------
Dr Andy Carpenter
School of Computer Science,
University of Manchester, Manchester M13 9PL, UK
Email: Andy.Carpenter@manchester.ac.uk
Tel: +44 161 275 6168
Fax: +44 161 275 6280
Re: [TCS] multi-step reference resolution [message #380831 is a reply to message #380825] Mon, 07 January 2008 14:42 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 #380847 is a reply to message #380845] Thu, 10 January 2008 13:54 Go to previous message
Andy Carpenter is currently offline Andy CarpenterFriend
Messages: 145
Registered: July 2009
Senior Member
Mikael,

Thanks. You're proposed workaround is very similar
to the one that I used.

Andy.

"Mika
Re: [TCS] multi-step reference resolution [message #611111 is a reply to message #380825] Mon, 07 January 2008 14:42 Go to previous message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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 #611164 is a reply to message #380845] Thu, 10 January 2008 13:54 Go to previous message
Andy Carpenter is currently offline Andy CarpenterFriend
Messages: 145
Registered: July 2009
Senior Member
Mikael,

Thanks. You're proposed workaround is very similar
to the one that I used.

Andy.

"Mika
Previous Topic:[AM3] Am3 installation problem
Next Topic:[AM3]Strange situations
Goto Forum:
  


Current Time: Fri Mar 29 14:45:41 GMT 2024

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

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

Back to the top