Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] Issue 13268: Ordered Tuples

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 <ed@xxxxxxxxxxxxx> 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 <ed@xxxxxxxxxxxxx>
Date: Monday, January 6, 2014 3:38 AM
To: "qvt-rtf@xxxxxxx" <qvt-rtf@xxxxxxx>, QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev



Back to the top