eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[pivot] Support OrderedCollection co-iterators #2214

Open eclipse-ocl-bot opened 5 days ago

eclipse-ocl-bot commented 5 days ago

| --- | --- | | Bugzilla Link | 577614 | | Status | NEW | | Importance | P3 normal | | Reported | Dec 03, 2021 08:02 EDT | | Modified | Jun 20, 2022 05:02 EDT | | Blocks | 580212 | | Reporter | Ed Willink |

Description

Acceleo provides a magic "i" variable that can be used to access the index during an OrderedCollection iteration avoiding the overhead of an indexOf().

Map support introduced co-iterators for key<-value pairs as iterators.

The same syntax could support e.g.

...->forAll(value <- index | ...)

for OrderedCollections.

eclipse-ocl-bot commented 5 days ago

By Ed Willink on Dec 13, 2021 11:09

value <- index

This is sensible. From index we can map to value (the index'th ordered collection element)

But key<-value is now clearly inconsistent. Let's change to value <- key before it's too ingrained.

eclipse-ocl-bot commented 5 days ago

By Ed Willink on Dec 13, 2021 15:28

Yes. But there is a semantic inconsistency.

For OrderedCollections, "value <- index" is a long form of "value". Simple iteration is over the collections contents not indexes.

For Maps, "value <- key" is a long form of "key". Simple iteration is over the map keys not values. (A map is a set with co-values).

MapLiteralExpCS is parsed as key<-value so that must break.

Ouch! this is really painful, quite apart from the tedium of swapping many JUnit test arguments, the EssentialOCLCSLeft2RightVisitor parsing mut flip aruments for dual iterator Map, and EssentialOCLCSContainmentVisitor must flip constructed types before it os known that a Map needs flipping. ... AS2CS too ... Must be a better way.

eclipse-ocl-bot commented 5 days ago

By Ed Willink on Dec 17, 2021 04:09

(In reply to Ed Willink from comment #2)

Ouch! this is really painful

Eliminating the new CoIteratorVariable so that we have just two IteratorVariable terms solves the timing problem, but the new ordering:

Map(Integer[?],String[1]){'1' <- 1}->forAll(value <- key |  ...

is dreadful: K-then-V, V-then-K, V-then-K.

Key as the first Map argument has a massive Java etc tradition. The rationalisation of Map as a Set with co-values almost mandates the unique Key first. so the current ordering of

Map(Integer[?],String[1]){1 <- '1'}->forAll(key <- value|  ...

is at least positionally consistent,it is just the "<-" spelling that is bad. It was chosen to minimize distinctive new punctuation without overloading "->". Not good enough. The operator has the long-form meaning.

key is-a-key-for-value value

but in the direction of the arrow it should be read s is-located-by which is unhelpful and violates the obvious execution as a lookup from key to co-value.

We just need a new good left-to-right spelling.

->, =>, and, implies, gives, yields, provides,

Using a Thesuarus: adds, keeps, produces

Overloads are cute and dangerous, => is too close to >=, new keywords are undesirable.

Ah! key/index plus co-value ... what about "with"?

Map(Integer[?],String[1]){1 with '1'}->forAll(key with value |  ...

Positionally good, short, not already used, once correlated with the co-value concept, clear, mnemonic and suitable for both keys and indexes.

"with" is not used by QVTc, QVTr, MOFM2T. It is used by QVTo but only as subsidiary punctuation for 'assert' so there should be no insuperable ambiguity.

eclipse-ocl-bot commented 5 days ago

By Ed Willink on Dec 17, 2021 05:13

(In reply to Ed Willink from comment #3)

Ah! key/index plus co-value ... what about "with"?

Map(Integer[?],String[1]){1 with '1'}->forAll(key with value |  ...

Even better, what about "to"?

 Map(Integer[?],String[1]){1 to '1'}->forAll(key to value |  ...

"to" is not a keyword in QVT or MOFM2T and is so short that it's not that common as a user variable.

eclipse-ocl-bot commented 5 days ago

By Ed Willink on Dec 17, 2021 06:13

(In reply to Ed Willink from comment #4)

"to" is not a keyword in QVT or MOFM2T and is so short that it's not that common as a user variable.

In Java, but "to" is fairly natural as a model property name. Two OCL tests fail becuase of a "to" property, and one QVTr becuase of a "to" domain. Just need to escape. Ashame but probably the least bad option for a new syntax.

eclipse-ocl-bot commented 5 days ago

By Ed Willink on Dec 17, 2021 08:42

(In reply to Ed Willink from comment #4)

"to" is not a keyword in QVT or MOFM2T and is so short that it's not that common as a user variable.

But it doesn't unambiguously mean "mapsTo". It too easily means a range and so a casual reader may try to interpret "x to y" in an iteration call as some kind of sub-collection.

Back to "with" for which the ordered collection "index with iterator" could equally easily be "iterator with index", allowing the simplification that the LHS of an optional "with" is always the natural/shorter-form iterator (map-key/collection-value) and the oRHS when present is the extra-iterator (map-value/ordered-collection-index). Easier to explain - no shorter form irregularity. Easy to parse, lexical LHS is alwys the AS iterator, lexivcal RHS is always theoptional co-iterator.

(In reply to Ed Willink from comment #0)

...->forAll(value <- index | ...)

so

 ...->forAll(value with index | ...)