[pivot] Clarify ParameterVariable / Parameter

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 580356 | | Status | NEW | | Importance | P3 normal | | Reported | Jul 08, 2022 04:12 EDT | | Modified | Nov 05, 2022 13:32 EDT | | Blocks | 509309 | | See also | 551822, 481664, 509309, 580359 | | Reporter | Ed Willink |

Description

There seems to be confusion between ParameterVariable / Parameter leading to some pragmatic coding for either. It should be clear.

An Operation/Function defininition has Parameter/FunctionParameter and probably has an ExpressionInOCL body and may have further ExpressionInOCL pre/post-conditions.

An ExpressionInOCL has ParameterVariable and an OCLExpression body.

The ExpressionInOCL ParameterVariable has a representedParameter to identify the defining Operation Parameter.

A VariableExp will transitively form part of an ExpresssionInOCL's OCLExpression body and so should have a referredVariable referencing the ParameterVariable, not the Parameter.

?? A VariableExp should never reference a Parameter ??

[eclipse-ocl-bot]

By Ed Willink on Jul 08, 2022 05:13

?? A VariableExp should never reference a Parameter ??

assert !(newReferredVariable instanceof Parameter);

in VariableExpImpl.setReferredVariable(VariableDeclaration newReferredVariable)

gives no problems for all OCL standalone tests but hits prolific QVTd problems.

Transformation.ownedContext is a Parameter which is consistent with a definition. But it is referenced directly by "this".

Where is the intervening 'ExpressionInOCL' that provides the intervening ParameterVariable?

Narrowly it could be in Predicate that has a conditionExpression, but a Pattern may have many Predicates, so in Pattern has less bloat, ... in Domain, ... in Mapping/Relation/Rule has minimal bloat. It just recognises that in addition to domain binding there is a common transformation 'binding'.

So add Rule.ownedContext : ParameterVariable[?].

QVTbaseUtil.getContextVariable(standardLibrary, containingTransformation) still returns the Transformation.ownedContext Parameter.

Add QVTbaseUtil.getContextVariable(standardLibrary, containingRule) returning the Rule.ownedContext ParameterVariable.

[eclipse-ocl-bot]

By Ed Willink on Jul 08, 2022 05:53

(In reply to Ed Willink from comment #1)

So add Rule.ownedContext : ParameterVariable[?].

Yes but "this" is also accessed in Function which has a queryExpression that conflicted with the inherited Operation's ExpressionInOCL. Fortunately Bug 481664 cleaned up Function so that it is now like a regular Operation. Just need to ensure that its context ParameterVariable is available in time.

[eclipse-ocl-bot]

By Ed Willink on Jul 09, 2022 02:42

Reassigning to QVTd since the bug is primarily the missing "this" ParameterVariable.

Parameter is the binding of a capability referenced by a potential invocation.

ParameterVariable is the actual binding of the capability for use by the actual invocation execution.

Binding occurs during relation invocation so it is Rule that should have a context ParameterVariable.

---

Adding Rule.ownedContext : ParameterVariable is straightforward but the validation of Function's body fails if we try to ensure that Function (inheriting Operation) lazily initializes its body. Maybe we can get rid of the FunctionBody pragmatism.

---

Once this is sorted we can ensure that e.g. VariableDeclaration::representedParameter is only used by ParameterVariable (or IteratorVariable). Various PivotUtil APIs can be narrowed.

[eclipse-ocl-bot]

By Ed Willink on Nov 02, 2022 04:05

Reassigning back to OCL.

?? A VariableExp should never reference a Parameter ??

This proves very uncomfortable since a Transformation and TypedModel must have both a contextParameter and a contextVariable that present legacy load difficulties.

Rethink.

Why do we have ParameterVariable and consequently ParameterVariable.representedParameter at all. Becuase ExpressionInOCL duplicates the paramter list. Why?

A Variable is just a name-type that may be used in expressions and looked up in the prevailing evaluation environment at run-time. A Parameter is fully suitable for this.

ExpressionInOCL is the necessary glue to bridge the gap between a UML ValueSpecification and an OCLExpression. Each ExpressionInOCL ParamterVariable.representedParameter refers back to Operation Parameter, so rather than duplicating the parameter list why not just have ExpressionInOCL have a 'representedOperation' that provides the parameters and an owningClass that provides a single shared self/context Parameter?

A TypedModel can similarly provide a 'self' parameter.

A Transformation inherits a self/context Parameter from Class and if really necessary can have a further this/transformation Parameter. No need for struggles to emulate EXpressionInOCL ParameterVariable in Rule/TypedModel/Transformation.

?? A VariableExp should never reference a Parameter ??

Quite the reverse. In order to make progress to obsoleting ExpressionInOCL duplication:

A VariableExp should never not-reference a Parameter

Therefore wherever a Variable is used the representedParameter should be followed so that lookups always use the represented concept.

[eclipse-ocl-bot]

By Ed Willink on Nov 02, 2022 05:47

(In reply to Ed Willink from comment #4)

Therefore wherever a Variable is used the representedParameter should be followed so that lookups always use the represented concept.

No.

The ParameterVariable/Parameter duality supports the traditional freedom to use variant parameter names throughout an overload hierarchy; only typing must be consistent. (The dubious use case of a Complete OCL Function using a non-standard spelling of self is a minor detail.)

When parsing, only ParameterVariable names may be referenced; representedParameter must not be followed. paramters are not visible.

When serializing, the ParameterVariable should be regenerated; the ParamterVariable must not be lost.

Therefore in the AS VariableExp must reference the ParameterVariable (when one is available).

For run-time evaluation the VariableExp must traverse the representedParameter so that only one entry is needed for lookups.

For Property.defaultExpression which is (eventually) an ExpressionInOCL, there are no parameters, but there is a 'self' which is currently a ParameterVariable with a null representedParameter since there is no shared Class parameter. Since 'self' cannot be re-spelled within a Property defaultExpression, it might seem that ExpressionInOCL could be bypassed except we need the ability to start with a text expression that lazily promotes to an ASG.

---

We have three usages for a parameter (re-)declaration:

Just Parameter: self/this of a Rule (and simpler Property)\ ParameterVariable->Parameter: parameter of an Operation\ ParameterVariable->null: self of an Operation / Property

It is the irregularity of ParameterVariable->null that start to cause trouble and the bloat of ParameterVariable->Parameter when no rename is appropriate that compounds the trouble.

If we have a Class.ownedContext : Parameter, then ParameterVariable->null is not needed and ParameterVariable->Parameter is used precisely for potential rename by ExpressionInOCL.

A VariableExp below a renaming ExpressionInOCL must always reference a ParameterVariable->Parameter, else a VariableExp must not reference a ParameterVariable.

For legacy purposes, ParameterVariable->null can be lazily redirected to the containingClass' ownedContext.

[eclipse-ocl-bot]

By Ed Willink on Nov 02, 2022 06:16

(In reply to Ed Willink from comment #5)

It is the irregularity of ParameterVariable->null that start to cause trouble and the bloat of ParameterVariable->Parameter when no rename is appropriate that compounds the trouble.

But fixing it changes OCL API a bit. Prefer to avoid more trouble. If Mapping/Transformation/TypedModel ownedContext are ParameterVariable->null, we should be able to move on.

[eclipse-ocl-bot]

By Ed Willink on Nov 05, 2022 13:32

(In reply to Ed Willink from comment #5)

A VariableExp below a renaming ExpressionInOCL must always reference a ParameterVariable->Parameter, else a VariableExp must not reference a ParameterVariable.

No. asserts fail.

This is easily seen for an IteratorVariable for which there may be multiple represented itertors in scope. We must lookup the IteratorVariable to ensure we use the right one.

Similarly inlined Operations must use the appropriate ParameterVariable. Nested Operations may also need to use the correctly nested ParameterVariable.

Therefore any execution context that may have more that one evaluation in scope must use ParameterVariable/IteratorVariable and the representedParameter is just a convenience bloat.

(Mappings do not nest at run-time so ParameterVariable is not needed.)