Re: [qvto-dev] [omg] [QVT13] Ballot #1 is ready for review until Wed, 7

[Christopher Gerking <christopher.gerking@xxxxxxxxxxxxxxxx>]

Hi

 

Please consider the corresponding Bugzilla as well: https://bugs.eclipse.org/bugs/show_bug.cgi?id=432112

 

If the result tuple remains available, what happens to it if only a single element is assigned?

 

mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {

init {

result := h1();

r1 := x; // what happens to the result tuple?

}

} 

 

Tuples are immutable. So we would need a special handling for this kind of assignments, creating a new tuple that is a partial copy of the old tuple.

 

I think this introduces too many special cases. What about ordinary tuple variables? Would this kind of assignment work for them as well?

 

 

Regards

Christopher

 

 

Von: Sergey Boyko [mailto:serg.boyko2011@xxxxxxxxx]
Gesendet: Dienstag, 6. Oktober 2015 10:48
An: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
Cc: Ed Willink <ed@xxxxxxxxxxxxx>; Christopher Gerking <christopher.gerking@xxxxxxxxxxxxxxxx>
Betreff: Re: [omg] [QVT13] Ballot #1 is ready for review until Wed, 7 Oct 2015 04:00 GMT.

 

Hello,

 

I'll comment 'Balot 1' issues using qvto-dev-list since I'm not registered at OMG site.

 

 

I understand that issue QVT13-28 was inspired by [Bug 432112] "Inconsistency between scoped/unscoped result identifiers". However after some studies I see some inconvenience with the proposed solution.

 

Consider the following snippet:

 

mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {

} 

 

helper h1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {

   // return Tuple { ... };

}

 

helper h2(t : Tuple(r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass)) {

   // ...

}

 

 

First case.

Suppose we need to initialize the former 'result' variable in m1() with the return value of h1().  With the accepted 'QVT13-28' (i.e. in case there's no 'result' variable) one have to do the following:

 

mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {

init {

var t := h1();

r1 := t.r1;

r2 := t.r2;

r3 := t.r3;

}

} 

 

However having 'result' in place the snippet above will look like:

 

mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {

init {

result := h1();

}

} 

 

 

 

Second case.

Suppose we need to pass the former 'result' variable to h2() somewhere in m1() population section.  With the accepted 'QVT13-28' (i.e. in case there's no 'result' variable) one have to do the following:

 

mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {

  h2(Tuple { r1 = r1, r2 = r2, r3 = r3 });

} 

 

However having 'result' in place the snippet above will look like:

 

mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {

h2(result);

} 

 

 

Overall conclusion.

I have the feeling that this issue was raised as a way to solve some implementation flaws in QVTO. I mean that there's no theoretical problems and only implementation difficulties are solved by the issue. 

 

To me the proposed modification impose more inconveniences than it tries to solve. And implementation flaws can be solved without intervention to specification.

 

 

 

Regards,

  Sergey

 

 

 

On Tue, Sep 29, 2015 at 4:46 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

 

OMG Issue: QVT13-28

Title:

Clarify availability of 'result' for Tuiple returns

Summary:

The current phrasing

Within a contextual operation <it>result</it> represents the unique result parameter (if there is a unique declared result) or the
tuple containing the list of declared result parameters.

suggests that the synthetic Tuple return is accessible as result. This is not necessary and imposes considerable implementation difficulties since a new Tuple would need creation with each mutation.

Sucggest the new wording.

Within a contextual operation for which no name is specified for a single return parameter, <it>result</it> is the implicit name of the parameter. If the name is specified explicitly, as is necessary for multiple returns, no pre-defined <it>result</it> variable exists.

Source:

ptc/14-03-38 — Chapter/Section: 8.1.16 — Page Number/s: 75

Legacy Issue Number:

19505

Reporter:

Ed Willink, Model Driven Solutions (ed@xxxxxxxxxxxxx)

Reported:

Wed, 2 Jul 2014 04:00 GMT on QVT 1.2

Updated:

Tue, 29 Sep 2015 13:26 GMT

Discussion:

QVT13-28

Proposal: Resolved

Summary:

Clarify availability of 'result' for Tuple returns

The current phrasing

Within a contextual operation result represents the unique result parameter (if there is a unique declared result) or the
tuple containing the list of declared result parameters.

suggests that the synthetic Tuple return is accessible as result. This is not necessary and imposes considerable implementation difficulties since a new Tuple would need creation with each mutation.

Suggest the new wording.

Within a contextual operation for which no name is specified for a single return parameter, result is the implicit name of the parameter. If the name is specified explicitly, as is necessary for multiple returns, no pre-defined result variable exists.

Discussion

Yes

Revised Text:

In "8.1.16 Pre-defined Variables: this, self, and result" replace

Within a contextual operation result represents the unique result parameter (if there is a unique declared result) or the tuple containing the list of declared result parameters.

by

Within a contextual operation for which no name is specified for a single return parameter, result is the implicit name of the parameter. If the name is specified explicitly, as is necessary for multiple returns, no pre-defined result variable exists.

Extent Of Change:

Minor

Created:

Fri, 25 Sep 2015 10:14 GMT

Updated:

Fri, 25 Sep 2015 10:19 GMT

Discussion:

QVT13-65