Issue 13268: Page 73: Section 8.2.1.11 Helper (qvt-rtf) Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody) Nature: Revision Severity: Minor Summary: Problem's text: "the invocation of the operation returns a tuple" discussion: it could be understood as an OCL Tuple, which doesn't apply. suggestion: Replace "a tuple" by "an ordered tuple". Resolution: The usage or OrderedTuple seems misguided since an ordinary OCL Tuple does very similar things without a positional hazard and without noticeable lexical overhead. Only the case of TupleLiteralEx/UnpackExp is plausibly defined in QVT 1.1 and neither of the QVT implementations (SmartQVT or Eclipse QVT) support OrderedTuple. Therefore eliminate TupleLiteralExp, UnpackExp and OrderedTupleType and OrderedTupleLiteralPart. Note that there are no editing instructions for the grammar. It is not clear that OrderedTuples were really supported at all. Revised Text: In 8.1.12 replace var f := lookForAFooInstance(); var (atom: Atom, bar: Bar) := f.foo2atombar(); by var f := lookForAFooInstance(); var t := f.foo2atombar(); – Tuple(atom: Atom, bar: Bar) var atom := t.atom; var bar := t.bar; In 8.1.14 replace These are mutable lists, dictionary types, and ordered tuples. by These are mutable lists and dictionary types. In 8.1.14 remove An ordered tuple is a tuple whose slots are unnamed. It can be manipulated in a more flexible way than tuples with named slots since it can be packed and unpacked more directly. var mytuple := Tuple{1,2,3}; // an ordered tuple literal var (x,y,z) := mytuple; // unpacking the tuple into three variables In Fig 8.4 remove UnpackExp In Fig 8.7 and accompanying explanatory text remove OrderedTupleType, OrderedTupleLiteralExp, OrderedTupleLiteralPart In 8.2.1.15 MappingOperation replace After call resolution, all the parameters of the mapping are passed as a tuple. The parameters include, in this order: the context parameter by After call resolution, the parameters of the mapping include: the context parameter In 8.2.2.16 ReturnExp replace If the operation declares more than one result parameter, the value is assigned to the tuple representing the collection of results. This requires that the type of the value passed to the result expressions is a tuple. by If the operation declares more than one return parameter, the result is a tuple with a tuple part for each return parameter. When the return expression value is omitted, this tuple is created automatically from the assignable result parameters. Alternatively the return expression value may be an explicitly constructed tuple with one part for each return parameter. Remove 8.2.2.22 UnpackExp Remove 8.2.2.27 OrderedTupleType Remove 8.2.2.31 OrderedTupleLiteralExp Remove 8.2.2.32 OrderedTupleLiteralPart In 8.3.3.1 repr remove Object::asOrderedTuple Actions taken: January 15, 2009: received issue July 15, 2014: closed issue Discussion: End of Annotations:===== s is issue # 13268 Page 73: Section 8.2.1.11 Helper Problem's text: "the invocation of the operation returns a tuple" discussion: it could be understood as an OCL Tuple, which doesn't apply. suggestion: Replace "a tuple" by "an ordered tuple". X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=G5klTbU5 c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=owxznbjw7CAA:10 a=f8N_gWvoJKL9qaca2V8A:9 a=WJ3BxufLh10VXydc:21 a=wPNLvfGTeEIA:10 a=_W_S_7VecoQA:10 Date: Mon, 06 Jan 2014 11:38:15 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: "qvt-rtf@omg.org" , QVTOML developer mailing list Subject: Issue 13268: Ordered Tuples X-Virus-Scanned: amavisd-new at omg.org Hi Please read at least as far as the ------------------------------------- separator. Apologies for this long email. I'm attempting to summarize some of the discussion on the Eclipse qvto-dev newsgroup and my more detailed analysis of the specification. The status of many things related to OrderedTuple in the QVTo specification is poor. We have a choice: a) Endorse OrderedTuple, fix the problems and look to promoting OrderedTuple to OCL. b) Treat OrderedTuple as misguided and look to deprecate it. My preference is to deprecate OrderedTuple/UnpackExp and write a longer Issue 13268 resolution accordingly. However if a strong case can be made for OrderedTuple, then an even longer 13268 resolution must fix the problems. Either way Issue 13268 is withdrawn from Ballot 1. You can skip the following analysis if you share my deprecation preference. Regards Ed Willink ---------------------------------------------------------------------------- The Pack/Unpack use case var a:A := ... var b:B := ... var t := Tuple{a, b}; // OrderedTupleLiteralExp ... var (a1,b1) := t; // UnpackExp An OrderedTupleLiteralExp followed by an UnpackExp allows miscellaneous information to be packed and unpacked without naming each element. This may sometimes give a lexical access saving in constrast to using OCL Tuples: var t := Tuple{a:A = ..., b:B = ...}; // TupleLiteralExp ... -- var a1 := t.a; -- var b2 := t.b; As the example shows, the overall saving is not necessarily large or even positive. OrderedTuples introduce a hazard from mis-aligned positional parts. However, this functionality is sufficiently clearly specified that outright removal would be a breaking change. Recommendation: deprecate OrderedTupleLiteralExp/UnpackExp etc as unnecessary bloat. The OrderedTuple::at() use case 8.2.2.7: Tuple elements can be accessed individually using the at pre-defined operation. Oops. The OrderedTuple::at() operation is not specified anywhere else. In particular, if at() was specified, its return type would be data dependent demonstrating the worst characteristics of reflection. In contrast, access to a Tuple part has a well-defined type and, if a reflective Tuple access was provided, there is a possibility that it could be type safe. Recommendation: Eliminate the suggestion that an at operation might exist. The Helper/Mapping return use case This issue started because of the bad wording for helper returns. If we try to construct a complete example we highlight new problems. The major example is in 8.1.2 mapping Foo::foo2atombar () : atom:Atom, bar:Bar merges foo2barPersistence, foo2atomFactory { object atom:{name := "A_"+self.name.upper();} object bar:{ name := "B_"+self.name.lower();} } This uses named returns and consequently an OCL Tuple return and so poses no real confusion (but see Merge footnote) Continuing we find var (atom: Atom, bar: Bar) := f.foo2atombar(); which unpacks an OCL Tuple return. This is not supported by an UnpackExp that requires an OrderedTuple. Surely it should be var t := f.foo2atombar(); -- var atom := t.atom; -- var bar := t.bar; There does not appear to be a full example of an OrderedTuple return. Reworking the example to use one, we could elimninate the return names giving mapping Foo::foo2atombar () : Atom, Bar merges foo2barPersistence, foo2atomFactory { Tuple{ object atom:{name := "A_"+self.name.upper();}, object bar:{ name := "B_"+self.name.lower();} } } and provide a specification that a list of unnamed return types e.g. "Atom, Bar" is a shorthand for "Tuple(Atom, Bar)" A Mapping of this form cannot do piecemeal assignment to the named result variables, so a great deal is lost and very little gained. Recommendation: implicit OrderedTuple return types have dubious benefits and are barely motivated by the specification so we can eliminate them A return must either be an optionally named Type or an OCL Tuple of named Types. The asOrderedTuple Use Case The Object::asOrderedTuple() : OrderedTuple(T) library function provides a limited reflective capability with a rather poor description. Converts the object into an ordered tuple. If the object is already an ordered type, no change is done. What is an ordered type? Is a Sequence or List an ordered type? If the object is an OCL Tuple, the list of attributes become the anonymous content of the ordered tuple. Is this really intended? I would expect the values to become the content. Either way this is a non-determinstic conversion. Otherwise, the operation creates a new tuple with a unique element being the object. I guess it means a single element OrderedTuple containing the source, but for a class, I would really like to see the properties/values. The above functionlity would appear to be provided by Tuple::keys() : Set(TypedElement) to get a set of the Tuple name+type parts. Tuple::at(TypedElement) : OclAny to get a selected part value and extended by OclElement::asTuple() : Tuple to give a Tuple of name+type+value parts. Recommendation: deprecate asOrderedTuple in favour of Tuple::keys/at in OCL. Merge footnote In 8.1.2 we find We should note that conceptually a result parameter is treated as an optional parameter of the mapping operation. Thus, the first call of .f.foo2atombar(). is equivalent to invoke .f.foo2atombar(null,null).. This seems to be absolute rubbish. But it might make some kind of sense once someone specifies the subtleties of merge semantics. If merge is a lexical mash, then no passing is needed. If merge is a disciplined call sequence, then good sharing is needed. Anyway that's a different issue. X-IronPort-AV: E=Sophos;i="4.95,612,1384300800"; d="scan'208,217";a="72742773" From: Akehurst David To: Ed Willink , "qvt-rtf@omg.org" , QVTOML developer mailing list Date: Mon, 6 Jan 2014 11:53:42 +0000 Subject: RE: Issue 13268: Ordered Tuples Thread-Topic: Issue 13268: Ordered Tuples Thread-Index: Ac8K0/xERyHqJS7FTUm3r3LBz3HfrAAAdRFQ Accept-Language: en-US, en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB X-SpamInfo: helo-dns, X-Virus-Scanned: amavisd-new at omg.org OrderedTuple looks like a misguided thing to me. From: Ed Willink [mailto:ed@willink.me.uk] Sent: 06 January 2014 11:38 To: qvt-rtf@omg.org; QVTOML developer mailing list Subject: Issue 13268: Ordered Tuples Hi Please read at least as far as the ------------------------------------- separator. Apologies for this long email. I'm attempting to summarize some of the discussion on the Eclipse qvto-dev newsgroup and my more detailed analysis of the specification. The status of many things related to OrderedTuple in the QVTo specification is poor. We have a choice: a) Endorse OrderedTuple, fix the problems and look to promoting OrderedTuple to OCL. b) Treat OrderedTuple as misguided and look to deprecate it. My preference is to deprecate OrderedTuple/UnpackExp and write a longer Issue 13268 resolution accordingly. However if a strong case can be made for OrderedTuple, then an even longer 13268 resolution must fix the problems. Either way Issue 13268 is withdrawn from Ballot 1. You can skip the following analysis if you share my deprecation preference. Regards Ed Willink ---------------------------------------------------------------------------- The Pack/Unpack use case var a:A := ... var b:B := ... var t := Tuple{a, b}; // OrderedTupleLiteralExp ... var (a1,b1) := t; // UnpackExp An OrderedTupleLiteralExp followed by an UnpackExp allows miscellaneous information to be packed and unpacked without naming each element. This may sometimes give a lexical access saving in constrast to using OCL Tuples: var t := Tuple{a:A = ..., b:B = ...}; // TupleLiteralExp ... -- var a1 := t.a; -- var b2 := t.b; As the example shows, the overall saving is not necessarily large or even positive. OrderedTuples introduce a hazard from mis-aligned positional parts. However, this functionality is sufficiently clearly specified that outright removal would be a breaking change. Recommendation: deprecate OrderedTupleLiteralExp/UnpackExp etc as unnecessary bloat. The OrderedTuple::at() use case 8.2.2.7: Tuple elements can be accessed individually using the at pre-defined operation. Oops. The OrderedTuple::at() operation is not specified anywhere else. In particular, if at() was specified, its return type would be data dependent demonstrating the worst characteristics of reflection. In contrast, access to a Tuple part has a well-defined type and, if a reflective Tuple access was provided, there is a possibility that it could be type safe. Recommendation: Eliminate the suggestion that an at operation might exist. The Helper/Mapping return use case This issue started because of the bad wording for helper returns. If we try to construct a complete example we highlight new problems. The major example is in 8.1.2 mapping Foo::foo2atombar () : atom:Atom, bar:Bar merges foo2barPersistence, foo2atomFactory { object atom:{name := "A_"+self.name.upper();} object bar:{ name := "B_"+self.name.lower();} } This uses named returns and consequently an OCL Tuple return and so poses no real confusion (but see Merge footnote) Continuing we find var (atom: Atom, bar: Bar) := f.foo2atombar(); which unpacks an OCL Tuple return. This is not supported by an UnpackExp that requires an OrderedTuple. Surely it should be var t := f.foo2atombar(); -- var atom := t.atom; -- var bar := t.bar; There does not appear to be a full example of an OrderedTuple return. Reworking the example to use one, we could elimninate the return names giving mapping Foo::foo2atombar () : Atom, Bar merges foo2barPersistence, foo2atomFactory { Tuple{ object atom:{name := "A_"+self.name.upper();}, object bar:{ name := "B_"+self.name.lower();} } } and provide a specification that a list of unnamed return types e.g. "Atom, Bar" is a shorthand for "Tuple(Atom, Bar)" A Mapping of this form cannot do piecemeal assignment to the named result variables, so a great deal is lost and very little gained. Recommendation: implicit OrderedTuple return types have dubious benefits and are barely motivated by the specification so we can eliminate them A return must either be an optionally named Type or an OCL Tuple of named Types. The asOrderedTuple Use Case The Object::asOrderedTuple() : OrderedTuple(T) library function provides a limited reflective capability with a rather poor description. Converts the object into an ordered tuple. If the object is already an ordered type, no change is done. What is an ordered type? Is a Sequence or List an ordered type? If the object is an OCL Tuple, the list of attributes become the anonymous content of the ordered tuple. Is this really intended? I would expect the values to become the content. Either way this is a non-determinstic conversion. Otherwise, the operation creates a new tuple with a unique element being the object. I guess it means a single element OrderedTuple containing the source, but for a class, I would really like to see the properties/values. The above functionlity would appear to be provided by Tuple::keys() : Set(TypedElement) to get a set of the Tuple name+type parts. Tuple::at(TypedElement) : OclAny to get a selected part value and extended by OclElement::asTuple() : Tuple to give a Tuple of name+type+value parts. Recommendation: deprecate asOrderedTuple in favour of Tuple::keys/at in OCL. Merge footnote In 8.1.2 we find We should note that conceptually a result parameter is treated as an optional parameter of the mapping operation. Thus, the first call of .f.foo2atombar(). is equivalent to invoke .f.foo2atombar(null,null).. This seems to be absolute rubbish. But it might make some kind of sense once someone specifies the subtleties of merge semantics. If merge is a lexical mash, then no passing is needed. If merge is a disciplined call sequence, then good sharing is needed. Anyway that's a different issue. From: "Rouquette, Nicolas F (313D)" To: Ed Willink , "qvt-rtf@omg.org" , "QVTOML developer mailing list" Subject: Re: Issue 13268: Ordered Tuples Thread-Topic: Issue 13268: Ordered Tuples Thread-Index: AQHPCtPksyRECxit60m9vZOTdMJORJp3/EAA Date: Mon, 6 Jan 2014 17:58:52 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Ed, OrderedTupleType seems misguided to me as well. I checked the Eclipse QVTO implementation, which we use extensively at JPL. OrderedTupleType is defined in the Eclipse QVTO http://www.eclipse.org/qvt/1.0/ImperativeOCL metamodel. There is no unit test based on the syntax of OrderedTupleTypes. In practice, I believe that Eclipse QVTO supports only TupleType, not OrderedTupleType. Unlike the QVT 1.1 spec, Eclipse QVTO packs return parameters in a TupleType, not an OrderedTupleType. transformation TupleTests(); intermediate class A { id : String }; constructor A::A(_id : String) { result.id := _id; } main() { var i1 : A = new A('i'); var i2 : A = new A('j'); //var t1 := Tuple{i1,i2}; // error: "=" expected instead of "," //var x1 := t1.at(1); //var y1 := t1.at(2); var t2 := Tuple{x=i1,y=i2}; var x2 := t2.x; var y2 := t2.y; var r : Tuple(x:A, y:A) = map foo('test'); var rx := r.x; var ry := r.y; assert fatal (rx.id='testx'); assert fatal (ry.id='testy'); } mapping foo(in prefix:String) : x:A, y:A { init { x := new A(prefix+'x'); y := new A(prefix+'y'); } } - Nicolas. From: Ed Willink Date: Monday, January 6, 2014 3:38 AM To: "qvt-rtf@omg.org" , QVTOML developer mailing list Subject: Issue 13268: Ordered Tuples Hi Please read at least as far as the ------------------------------------- separator. Apologies for this long email. I'm attempting to summarize some of the discussion on the Eclipse qvto-dev newsgroup and my more detailed analysis of the specification. The status of many things related to OrderedTuple in the QVTo specification is poor. We have a choice: a) Endorse OrderedTuple, fix the problems and look to promoting OrderedTuple to OCL. b) Treat OrderedTuple as misguided and look to deprecate it. My preference is to deprecate OrderedTuple/UnpackExp and write a longer Issue 13268 resolution accordingly. However if a strong case can be made for OrderedTuple, then an even longer 13268 resolution must fix the problems. Either way Issue 13268 is withdrawn from Ballot 1. You can skip the following analysis if you share my deprecation preference. Regards Ed Willink ---------------------------------------------------------------------------- The Pack/Unpack use case var a:A := ... var b:B := ... var t := Tuple{a, b}; // OrderedTupleLiteralExp ... var (a1,b1) := t; // UnpackExp An OrderedTupleLiteralExp followed by an UnpackExp allows miscellaneous information to be packed and unpacked without naming each element. This may sometimes give a lexical access saving in constrast to using OCL Tuples: var t := Tuple{a:A = ..., b:B = ...}; // TupleLiteralExp ... -- var a1 := t.a; -- var b2 := t.b; As the example shows, the overall saving is not necessarily large or even positive. OrderedTuples introduce a hazard from mis-aligned positional parts. However, this functionality is sufficiently clearly specified that outright removal would be a breaking change. Recommendation: deprecate OrderedTupleLiteralExp/UnpackExp etc as unnecessary bloat. The OrderedTuple::at() use case 8.2.2.7: Tuple elements can be accessed individually using the at pre-defined operation. Oops. The OrderedTuple::at() operation is not specified anywhere else. In particular, if at() was specified, its return type would be data dependent demonstrating the worst characteristics of reflection. In contrast, access to a Tuple part has a well-defined type and, if a reflective Tuple access was provided, there is a possibility that it could be type safe. Recommendation: Eliminate the suggestion that an at operation might exist. The Helper/Mapping return use case This issue started because of the bad wording for helper returns. If we try to construct a complete example we highlight new problems. The major example is in 8.1.2 mapping Foo::foo2atombar () : atom:Atom, bar:Bar merges foo2barPersistence, foo2atomFactory { object atom:{name := "A_"+self.name.upper();} object bar:{ name := "B_"+self.name.lower();} } This uses named returns and consequently an OCL Tuple return and so poses no real confusion (but see Merge footnote) Continuing we find var (atom: Atom, bar: Bar) := f.foo2atombar(); which unpacks an OCL Tuple return. This is not supported by an UnpackExp that requires an OrderedTuple. Surely it should be var t := f.foo2atombar(); -- var atom := t.atom; -- var bar := t.bar; There does not appear to be a full example of an OrderedTuple return. Reworking the example to use one, we could elimninate the return names giving mapping Foo::foo2atombar () : Atom, Bar merges foo2barPersistence, foo2atomFactory { Tuple{ object atom:{name := "A_"+self.name.upper();}, object bar:{ name := "B_"+self.name.lower();} } } and provide a specification that a list of unnamed return types e.g. "Atom, Bar" is a shorthand for "Tuple(Atom, Bar)" A Mapping of this form cannot do piecemeal assignment to the named result variables, so a great deal is lost and very little gained. Recommendation: implicit OrderedTuple return types have dubious benefits and are barely motivated by the specification so we can eliminate them A return must either be an optionally named Type or an OCL Tuple of named Types. The asOrderedTuple Use Case The Object::asOrderedTuple() : OrderedTuple(T) library function provides a limited reflective capability with a rather poor description. Converts the object into an ordered tuple. If the object is already an ordered type, no change is done. What is an ordered type? Is a Sequence or List an ordered type? If the object is an OCL Tuple, the list of attributes become the anonymous content of the ordered tuple. Is this really intended? I would expect the values to become the content. Either way this is a non-determinstic conversion. Otherwise, the operation creates a new tuple with a unique element being the object. I guess it means a single element OrderedTuple containing the source, but for a class, I would really like to see the properties/values. The above functionlity would appear to be provided by Tuple::keys() : Set(TypedElement) to get a set of the Tuple name+type parts. Tuple::at(TypedElement) : OclAny to get a selected part value and extended by OclElement::asTuple() : Tuple to give a Tuple of name+type+value parts. Recommendation: deprecate asOrderedTuple in favour of Tuple::keys/at in OCL. Merge footnote In 8.1.2 we find We should note that conceptually a result parameter is treated as an optional parameter of the mapping operation. Thus, the first call of .f.foo2atombar(). is equivalent to invoke .f.foo2atombar(null,null).. This seems to be absolute rubbish. But it might make some kind of sense once someone specifies the subtleties of merge semantics. If merge is a lexical mash, then no passing is needed. If merge is a disciplined call sequence, then good sharing is needed. Anyway that's a different issue. X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=G5klTbU5 c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=EJ1lp_l6QloA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=GsjBg7t8fcQA:10 a=JIVOxcAaAAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=2iJcPf2g_p-9OGqHEg0A:9 a=Yh02rqj35QhMCMNU:21 a=mmqB-6qfTC5ijyxj:21 a=lnOTb3j19_zc75RB:21 a=pILNOxqGKmIA:10 a=_W_S_7VecoQA:10 a=WP4_USCxRkkA:10 a=R4QD78S-XS0A:10 Date: Mon, 06 Jan 2014 18:08:26 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: "Rouquette, Nicolas F (313D)" , "qvt-rtf@omg.org" , QVTOML developer mailing list Subject: Re: Issue 13268: Ordered Tuples X-Virus-Scanned: amavisd-new at omg.org Hi Thanks. You were one of the most likely users to come up with a must-have use case. Yes, we are well aware that Eclipse QVTo is deficient for OrderedTuples. But just because an implementation is bad doesn't necessarily mean the specification is bad. Regards Ed Willink On 06/01/2014 17:58, Rouquette, Nicolas F (313D) wrote: Ed, OrderedTupleType seems misguided to me as well. I checked the Eclipse QVTO implementation, which we use extensively at JPL. OrderedTupleType is defined in the Eclipse QVTO http://www.eclipse.org/qvt/1.0/ImperativeOCL metamodel. There is no unit test based on the syntax of OrderedTupleTypes. In practice, I believe that Eclipse QVTO supports only TupleType, not OrderedTupleType. Unlike the QVT 1.1 spec, Eclipse QVTO packs return parameters in a TupleType, not an OrderedTupleType. transformation TupleTests(); intermediate class A { id : String }; constructor A::A(_id : String) { result.id := _id; } main() { var i1 : A = new A('i'); var i2 : A = new A('j'); //var t1 := Tuple{i1,i2}; // error: "=" expected instead of "," //var x1 := t1.at(1); //var y1 := t1.at(2); var t2 := Tuple{x=i1,y=i2}; var x2 := t2.x; var y2 := t2.y; var r : Tuple(x:A, y:A) = map foo('test'); var rx := r.x; var ry := r.y; assert fatal (rx.id='testx'); assert fatal (ry.id='testy'); } mapping foo(in prefix:String) : x:A, y:A { init { x := new A(prefix+'x'); y := new A(prefix+'y'); } } - Nicolas. From: Ed Willink Date: Monday, January 6, 2014 3:38 AM To: "qvt-rtf@omg.org" , QVTOML developer mailing list Subject: Issue 13268: Ordered Tuples Hi Please read at least as far as the ------------------------------------- separator. Apologies for this long email. I'm attempting to summarize some of the discussion on the Eclipse qvto-dev newsgroup and my more detailed analysis of the specification. The status of many things related to OrderedTuple in the QVTo specification is poor. We have a choice: a) Endorse OrderedTuple, fix the problems and look to promoting OrderedTuple to OCL. b) Treat OrderedTuple as misguided and look to deprecate it. My preference is to deprecate OrderedTuple/UnpackExp and write a longer Issue 13268 resolution accordingly. However if a strong case can be made for OrderedTuple, then an even longer 13268 resolution must fix the problems. Either way Issue 13268 is withdrawn from Ballot 1. You can skip the following analysis if you share my deprecation preference. Regards Ed Willink ---------------------------------------------------------------------------- The Pack/Unpack use case var a:A := ... var b:B := ... var t := Tuple{a, b}; // OrderedTupleLiteralExp ... var (a1,b1) := t; // UnpackExp An OrderedTupleLiteralExp followed by an UnpackExp allows miscellaneous information to be packed and unpacked without naming each element. This may sometimes give a lexical access saving in constrast to using OCL Tuples: var t := Tuple{a:A = ..., b:B = ...}; // TupleLiteralExp ... -- var a1 := t.a; -- var b2 := t.b; As the example shows, the overall saving is not necessarily large or even positive. OrderedTuples introduce a hazard from mis-aligned positional parts. However, this functionality is sufficiently clearly specified that outright removal would be a breaking change. Recommendation: deprecate OrderedTupleLiteralExp/UnpackExp etc as unnecessary bloat. The OrderedTuple::at() use case 8.2.2.7: Tuple elements can be accessed individually using the at pre-defined operation. Oops. The OrderedTuple::at() operation is not specified anywhere else. In particular, if at() was specified, its return type would be data dependent demonstrating the worst characteristics of reflection. In contrast, access to a Tuple part has a well-defined type and, if a reflective Tuple access was provided, there is a possibility that it could be type safe. Recommendation: Eliminate the suggestion that an at operation might exist. The Helper/Mapping return use case This issue started because of the bad wording for helper returns. If we try to construct a complete example we highlight new problems. The major example is in 8.1.2 mapping Foo::foo2atombar () : atom:Atom, bar:Bar merges foo2barPersistence, foo2atomFactory { object atom:{name := "A_"+self.name.upper();} object bar:{ name := "B_"+self.name.lower();} } This uses named returns and consequently an OCL Tuple return and so poses no real confusion (but see Merge footnote) Continuing we find var (atom: Atom, bar: Bar) := f.foo2atombar(); which unpacks an OCL Tuple return. This is not supported by an UnpackExp that requires an OrderedTuple. Surely it should be var t := f.foo2atombar(); -- var atom := t.atom; -- var bar := t.bar; There does not appear to be a full example of an OrderedTuple return. Reworking the example to use one, we could elimninate the return names giving mapping Foo::foo2atombar () : Atom, Bar merges foo2barPersistence, foo2atomFactory { Tuple{ object atom:{name := "A_"+self.name.upper();}, object bar:{ name := "B_"+self.name.lower();} } } and provide a specification that a list of unnamed return types e.g. "Atom, Bar" is a shorthand for "Tuple(Atom, Bar)" A Mapping of this form cannot do piecemeal assignment to the named result variables, so a great deal is lost and very little gained. Recommendation: implicit OrderedTuple return types have dubious benefits and are barely motivated by the specification so we can eliminate them A return must either be an optionally named Type or an OCL Tuple of named Types. The asOrderedTuple Use Case The Object::asOrderedTuple() : OrderedTuple(T) library function provides a limited reflective capability with a rather poor description. Converts the object into an ordered tuple. If the object is already an ordered type, no change is done. What is an ordered type? Is a Sequence or List an ordered type? If the object is an OCL Tuple, the list of attributes become the anonymous content of the ordered tuple. Is this really intended? I would expect the values to become the content. Either way this is a non-determinstic conversion. Otherwise, the operation creates a new tuple with a unique element being the object. I guess it means a single element OrderedTuple containing the source, but for a class, I would really like to see the properties/values. The above functionlity would appear to be provided by Tuple::keys() : Set(TypedElement) to get a set of the Tuple name+type parts. Tuple::at(TypedElement) : OclAny to get a selected part value and extended by OclElement::asTuple() : Tuple to give a Tuple of name+type+value parts. Recommendation: deprecate asOrderedTuple in favour of Tuple::keys/at in OCL. Merge footnote In 8.1.2 we find We should note that conceptually a result parameter is treated as an optional parameter of the mapping operation. Thus, the first call of .f.foo2atombar(). is equivalent to invoke .f.foo2atombar(null,null).. This seems to be absolute rubbish. But it might make some kind of sense once someone specifies the subtleties of merge semantics. If merge is a lexical mash, then no passing is needed. If merge is a disciplined call sequence, then good sharing is needed. Anyway that's a different issue. No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6979 - Release Date: 01/06/14 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=G5klTbU5 c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=kFCf1NCnS5kA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=c7CBAQTbzycA:10 a=pGLkceISAAAA:8 a=JIVOxcAaAAAA:8 a=1-RJ_PGlAAAA:8 a=HGulIA7_AAAA:8 a=Fvzo_H0QAAAA:8 a=KHpXyVWLAAAA:8 a=CYuKiW2-AAAA:8 a=oCcaPWc0AAAA:8 a=PEqB4yy3-ZBlYCkMNuUA:9 a=MeV6zncAOncaNV4l:21 a=9mLwSISIoKqbu5Pe:21 a=4gUN8Fak3dKhfXtI:21 a=pILNOxqGKmIA:10 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=yXzQGvEYr6UA:10 a=WP4_USCxRkkA:10 a=R4QD78S-XS0A:10 a=qiWi7Edwir4A:10 a=NWVoK91CQyQA:10 Date: Tue, 07 Jan 2014 08:46:32 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: QVTOML developer mailing list CC: "qvt-rtf@omg.org" Subject: Re: [qvto-dev] Issue 13268: Ordered Tuples X-Virus-Scanned: amavisd-new at omg.org Hi Sergey Thanks. It seems we now have five people who see no use for OrderedTuple/UnpackExp, one person concerned about breaking changes and no one in favour of OrderedTuple/UnpackExp. With the specification in such poor shape and neither QVTo implementation supporting OrderedTuple, we can go straight to elimination rather than deprecation. Sergey: please wait till an OMG ballot passes before deleting any code. Regards Ed Willink On 06/01/2014 20:06, Sergey Boyko wrote: Hi, I've checked SmartQVT. It also does not support OrderedTuple type (thus OrderedTupleLiteralExp/UnpackExp). As I already wrote I don't see any real use cases which show benefit in supporting of OrderedTuple type. That is why OrderedTuple is at the end of the to-be-implemented features list. After reading related discussions I doubt that it will ever be implemented without explicit request from users. Regards, Sergey On Mon, Jan 6, 2014 at 10:08 PM, Ed Willink wrote: Hi Thanks. You were one of the most likely users to come up with a must-have use case. Yes, we are well aware that Eclipse QVTo is deficient for OrderedTuples. But just because an implementation is bad doesn't necessarily mean the specification is bad. Regards Ed Willink On 06/01/2014 17:58, Rouquette, Nicolas F (313D) wrote: Ed, OrderedTupleType seems misguided to me as well. I checked the Eclipse QVTO implementation, which we use extensively at JPL. OrderedTupleType is defined in the Eclipse QVTO http://www.eclipse.org/qvt/1.0/ImperativeOCL metamodel. There is no unit test based on the syntax of OrderedTupleTypes. In practice, I believe that Eclipse QVTO supports only TupleType, not OrderedTupleType. Unlike the QVT 1.1 spec, Eclipse QVTO packs return parameters in a TupleType, not an OrderedTupleType. transformation TupleTests(); intermediate class A { id : String }; constructor A::A(_id : String) { result.id := _id; } main() { var i1 : A = new A('i'); var i2 : A = new A('j'); //var t1 := Tuple{i1,i2}; // error: "=" expected instead of "," //var x1 := t1.at(1); //var y1 := t1.at(2); var t2 := Tuple{x=i1,y=i2}; var x2 := t2.x; var y2 := t2.y; var r : Tuple(x:A, y:A) = map foo('test'); var rx := r.x; var ry := r.y; assert fatal (rx.id='testx'); assert fatal (ry.id='testy'); } mapping foo(in prefix:String) : x:A, y:A { init { x := new A(prefix+'x'); y := new A(prefix+'y'); } } - Nicolas. From: Ed Willink Date: Monday, January 6, 2014 3:38 AM To: "qvt-rtf@omg.org" , QVTOML developer mailing list Subject: Issue 13268: Ordered Tuples Hi Please read at least as far as the ------------------------------------- separator. Apologies for this long email. I'm attempting to summarize some of the discussion on the Eclipse qvto-dev newsgroup and my more detailed analysis of the specification. The status of many things related to OrderedTuple in the QVTo specification is poor. We have a choice: a) Endorse OrderedTuple, fix the problems and look to promoting OrderedTuple to OCL. b) Treat OrderedTuple as misguided and look to deprecate it. My preference is to deprecate OrderedTuple/UnpackExp and write a longer Issue 13268 resolution accordingly. However if a strong case can be made for OrderedTuple, then an even longer 13268 resolution must fix the problems. Either way Issue 13268 is withdrawn from Ballot 1. You can skip the following analysis if you share my deprecation preference. Regards Ed Willink ---------------------------------------------------------------------------- The Pack/Unpack use case var a:A := ... var b:B := ... var t := Tuple{a, b}; // OrderedTupleLiteralExp ... var (a1,b1) := t; // UnpackExp An OrderedTupleLiteralExp followed by an UnpackExp allows miscellaneous information to be packed and unpacked without naming each element. This may sometimes give a lexical access saving in constrast to using OCL Tuples: var t := Tuple{a:A = ..., b:B = ...}; // TupleLiteralExp ... -- var a1 := t.a; -- var b2 := t.b; As the example shows, the overall saving is not necessarily large or even positive. OrderedTuples introduce a hazard from mis-aligned positional parts. However, this functionality is sufficiently clearly specified that outright removal would be a breaking change. Recommendation: deprecate OrderedTupleLiteralExp/UnpackExp etc as unnecessary bloat. The OrderedTuple::at() use case 8.2.2.7: Tuple elements can be accessed individually using the at pre-defined operation. Oops. The OrderedTuple::at() operation is not specified anywhere else. In particular, if at() was specified, its return type would be data dependent demonstrating the worst characteristics of reflection. In contrast, access to a Tuple part has a well-defined type and, if a reflective Tuple access was provided, there is a possibility that it could be type safe. Recommendation: Eliminate the suggestion that an at operation might exist. The Helper/Mapping return use case This issue started because of the bad wording for helper returns. If we try to construct a complete example we highlight new problems. The major example is in 8.1.2 mapping Foo::foo2atombar () : atom:Atom, bar:Bar merges foo2barPersistence, foo2atomFactory { object atom:{name := "A_"+self.name.upper();} object bar:{ name := "B_"+self.name.lower();} } This uses named returns and consequently an OCL Tuple return and so poses no real confusion (but see Merge footnote) Continuing we find var (atom: Atom, bar: Bar) := f.foo2atombar(); which unpacks an OCL Tuple return. This is not supported by an UnpackExp that requires an OrderedTuple. Surely it should be var t := f.foo2atombar(); -- var atom := t.atom; -- var bar := t.bar; There does not appear to be a full example of an OrderedTuple return. Reworking the example to use one, we could elimninate the return names giving mapping Foo::foo2atombar () : Atom, Bar merges foo2barPersistence, foo2atomFactory { Tuple{ object atom:{name := "A_"+self.name.upper();}, object bar:{ name := "B_"+self.name.lower();} } } and provide a specification that a list of unnamed return types e.g. "Atom, Bar" is a shorthand for "Tuple(Atom, Bar)" A Mapping of this form cannot do piecemeal assignment to the named result variables, so a great deal is lost and very little gained. Recommendation: implicit OrderedTuple return types have dubious benefits and are barely motivated by the specification so we can eliminate them A return must either be an optionally named Type or an OCL Tuple of named Types. The asOrderedTuple Use Case The Object::asOrderedTuple() : OrderedTuple(T) library function provides a limited reflective capability with a rather poor description. Converts the object into an ordered tuple. If the object is already an ordered type, no change is done. What is an ordered type? Is a Sequence or List an ordered type? If the object is an OCL Tuple, the list of attributes become the anonymous content of the ordered tuple. Is this really intended? I would expect the values to become the content. Either way this is a non-determinstic conversion. Otherwise, the operation creates a new tuple with a unique element being the object. I guess it means a single element OrderedTuple containing the source, but for a class, I would really like to see the properties/values. The above functionlity would appear to be provided by Tuple::keys() : Set(TypedElement) to get a set of the Tuple name+type parts. Tuple::at(TypedElement) : OclAny to get a selected part value and extended by OclElement::asTuple() : Tuple to give a Tuple of name+type+value parts. Recommendation: deprecate asOrderedTuple in favour of Tuple::keys/at in OCL. Merge footnote In 8.1.2 we find We should note that conceptually a result parameter is treated as an optional parameter of the mapping operation. Thus, the first call of .f.foo2atombar(). is equivalent to invoke .f.foo2atombar(null,null).. This seems to be absolute rubbish. But it might make some kind of sense once someone specifies the subtleties of merge semantics. If merge is a lexical mash, then no passing is needed. If merge is a disciplined call sequence, then good sharing is needed. Anyway that's a different issue. No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6979 - Release Date: 01/06/14 _______________________________________________ qvto-dev mailing list qvto-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/qvto-dev _______________________________________________ qvto-dev mailing list qvto-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/qvto-dev No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6980 - Release Date: 01/06/14