[pivot] Rationalize WildcardType as a TemplateParameter

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 581860 | | Status | NEW | | Importance | P3 normal | | Reported | Apr 25, 2023 03:38 EDT | | Modified | Sep 27, 2023 02:50 EDT | | Blocks | 581760 | | See also | 580407, 582115, 582158 | | Reporter | Ed Willink |

Description

Basic OCL has no templates and so no wildcards.

UML-aligned OCL has templates, but wildcards are unclear.

Ecore OCL has templates, and wildcards in declarations, but expressions are unclear.

(Java has templates and wildcards within expression declarations.)

THe Pivot OCL hastemplates and sort of has wildcards but really only to make Ecore roundtrip tests work. No use in expressions.

Bug 580407#c3 reports a tidy up introducing a WildcardId singleton in place of the vague UnspecifiedId.

Work on Bug 581760 suggests that WildcardId is not used and attempting to regularize specializations in the Orphanage high;ights an issue creating a typeid for Ecore wildcards. It seems that the current functionality gets awya with it since the usage is so minimal.

This to actually do some design.

[eclipse-ocl-bot]

By Ed Willink on Apr 25, 2023 03:57

If a WildcardType is a singleton type then each usage would be the same type. Clearly not so. A wildcard is just a lazily undeclared unnamed template parameter of the surrounding scope; it could be replaced by a binding of the surrounding scope.

e.g

operation f() ... let myMap : Map<?,Integer> = ...

could be rewritten as

operation f<QK>() ... let myMap : Map<QK,Integer> = ...

Each Wildcard is declared in a template signature/binding and is unique just as provided by the template signature ownership. Thus

Map<?,Integer> has a template signature comprising <?> and bindings comprising <?,Integer> of the general Map<K,V>. Map<?,Integer> is a partial specialization and so may have distinct parameter count from its full generalization.

A wildcard template parameter is conventionally spelled "?" and is contained by a template signature with a non-empty sibling template bindings.

A regular template parameter is conventionally spelled alphanumerically and is contained by a template signature with empty sibling template bindings.

Pivot processing can therefore ignore spelling (other than mandating non-null/non-empty name) using just the emptiness of the template bindings to distinguish usage. There is no need for a WildcardType or WildcardId. WildcardTypeRefCS is ok; it should just map to a TemplateParameter.

[eclipse-ocl-bot]

By Ed Willink on Jun 28, 2023 05:00

Bug 582115 identifies a clear need for the PIvot wildcard type.

[eclipse-ocl-bot]

By Ed Willink on Jul 01, 2023 02:50

(In reply to Ed Willink from comment #0)

This to actually do some design.

typo: Time to actually do some design

What is a Wildcard ? !

================================================

A (primary/declaration) Wildcard TemplateParameter as in

MyList<T>::addAll(MyList<?>) : MyList<T>

is a lazy/flexible way of specifying the corresponding TemplateParameter lowerbound. (lazy: user doesn't need to type it explicitly, flexible: declaration tracks underlying lowerbound.). The declaration is therefore probably equivalent to

MyList<T>::addAll(MyList<OclAny>) : MyList<T>

which exposes a declaration stupidity since the result template type may not accommodate all argument values. Should be

MyList<T>::addAll(MyList<T>) : MyList<T>

so that T is chosen as the common type.

In so far as we even support a Wildcard TemplateParameter, it is a TemplateParameter with a reserved "?" spelling delegating to the underlying TemplateParameter's lowerbound. A single Wildcard TemplateParameter per actual TemplateParameter can be shared/referenced as many times as required.

The user can specify an explicit extra declaration parameter.

================================================

A (secondary/redeclaration) Wildcard TemplateParameter as in

   Mapping.allInstances()->select(m : Mapping(?) | m.to = self)->notEmpty();

where mapping is a templated type. NB "(?)" may be omitted in the CS since it is inferrable. It is required in the AS.

This is again a lazy/flexible spelling of the lowerbound. Same singleton Wildcard TemplateParameter per actual TemplateParameter can be shared/referenced as many times as required.

Bug 582158 elaborates allInstances to support templates.

[eclipse-ocl-bot]

By Ed Willink on Jul 01, 2023 03:03

(In reply to Ed Willink from comment #3)

This is again a lazy/flexible spelling of the lowerbound. Same singleton Wildcard TemplateParameter per actual TemplateParameter can be shared/referenced as many times as required.

A complex usage may allow a stronger value to be deduced than the lowerbound.

Since wildcards are not normally used, we would like the singleton to be created lazily, perhaps as a transient of the underlying TemplateParameter, but it must be xmi referenceable so there is no alternative but to host the lazy singleton in the orphanage.

[eclipse-ocl-bot]

By Ed Willink on Sep 26, 2023 04:24

(In reply to Ed Willink from comment #3)

... Wildcard TemplateParameter ... can be shared/referenced

Same singleton Wildcard TemplateParameter per actual TemplateParameter

Singleton suggests that the Orphanage is a good place for the shared element. This all appears to work fine. But, oops, testCompanyRoundTrip reports an xmi:id collision when serialising; the LUSSID for distinct wildcards is not distinct.

The Orphanage is appropriate for aggregate types that have no logical scope other than 'global'. A wildcard is scoped, typically by an operation, and must be correspondingly distinct.

In f(Seq<?> u) { let Ord<?> v ...}

T is an explicit operation template parameter.\ Seq<?> u has an externally visible wildcard.\ Ord<?> v has an internal invisible wildcard.

externally visible wildcards must be matched up across overloads.

a) change a Wildcard to its logical TemplateParameter and host it in the TemplateSignature.ownedTemplateParameters. Good - simple structure. Bad - all usages of ownedTemplateParameters need to distinguish the 'implicit'

b) host a Wildcard as its logical TemplateParameter in a new TemplateSignature.ownedWildcards. Ok - clear but more complex structure.

c) infer a scoped Wildcard from a reference to the n'th local wildcard hosted in the orphanage. Bad - inference is opaque. Good - smaller serialization.

d) infer a scoped Wildcard from a magic n'th local wildcard TypedElement.wildcardIndex. Bad - inference is opaque and clumsy.

c) and d) seem horrible. Give b) a try to minimize ripples.

[eclipse-ocl-bot]

By Ed Willink on Sep 27, 2023 02:50

(In reply to Ed Willink from comment #5)

b) host a Wildcard as its logical TemplateParameter in a new TemplateSignature.ownedWildcards. Ok - clear but more complex structure.

This ripples by undermining the assurance that a non-null TemplateSignature has at least one TemplateParameter.

Bug 580407 has the same problem. Time to eliminate TemplateSignature.