Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community Forums[TCS] multi-step reference resolution
https://www.eclipse.org/forums/index.php/mv/msg/124482/380825/#msg_380825
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
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]]>Andy Carpenter2008-01-04T13:50:20-00:00Re: [TCS] multi-step reference resolution
https://www.eclipse.org/forums/index.php/mv/msg/124482/611111/#msg_611111
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/]]>2008-01-07T14:42:23-00:00Re: [TCS] multi-step reference resolution
https://www.eclipse.org/forums/index.php/mv/msg/124482/380831/#msg_380831
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/]]>2008-01-07T14:42:23-00:00Re: [TCS] multi-step reference resolution
https://www.eclipse.org/forums/index.php/mv/msg/124482/611160/#msg_611160
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
}
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/]]>2008-01-09T14:55:23-00:00Re: [TCS] multi-step reference resolution
https://www.eclipse.org/forums/index.php/mv/msg/124482/380843/#msg_380843
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
}
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/]]>2008-01-09T14:55:23-00:00Re: [TCS] multi-step reference resolution
https://www.eclipse.org/forums/index.php/mv/msg/124482/611162/#msg_611162
Originally posted by: mikael.barbero.gmail.com
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/]]>2008-01-09T15:44:35-00:00Re: [TCS] multi-step reference resolution
https://www.eclipse.org/forums/index.php/mv/msg/124482/380845/#msg_380845
Originally posted by: mikael.barbero.gmail.com
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/]]>2008-01-09T15:44:35-00:00Re: [TCS] multi-step reference resolution
https://www.eclipse.org/forums/index.php/mv/msg/124482/611164/#msg_611164
Thanks. You're proposed workaround is very similar
to the one that I used.
Andy.
"Mika]]>Andy Carpenter2008-01-10T13:54:12-00:00Re: [TCS] multi-step reference resolution
https://www.eclipse.org/forums/index.php/mv/msg/124482/380847/#msg_380847
Thanks. You're proposed workaround is very similar
to the one that I used.