Inconsistent language rules regarding dimensions in constraining type

[modelica-trac-importer]

Reported by petfr on 16 Aug 2013 06:25 UTC In Section 7.3.2 of MS 3.2 rev 2 we have the following:

... The number of dimension in the constraining type should correspond to the number of dimensions in the type-part and in the constraining type.. Similarly the type used in a redeclaration must have the same number of dimensions as the type of redeclared element. [Examples: replaceable T1 x[n] constrainedby T2; replaceable type T=T1[n] constrainedby T2; replaceable T1[n] x constrainedby T2; In these examples the number of dimensions must be the same in T1 and T2, as well as in a redeclaration. Normally T1 and T2 are scalar types, but both could also be defined as array types – with the same number of dimensions. Thus if T2 is a scalar type (e.g. type T2= Real) then T1 must also be a scalar type; and if T2 is defined as vector type (e.g. type T2=Real[3]) then T1 must also be vector type.] ...

The simple intuitive rule regarding constraining type is that it gives a type constraint (supertype) regarding a replaceable type or type of a replaceable component, e.g.:

replaceable type Mytype=T constrainedby T2; replaceable Mytype x constrainedby T2;

In both cases Mytype must be a subtype of T2.

According to the same reasoning, the following should be correct, since Real[2] is a subtype of Real[:]

replaceable type T=Real[2] constrainedby Real[:]; replaceable Real[2] x constrainedby Real[:];

But according the the above text in MS 3.2 rev 2 with T1=Real and T2 = Real, it should be as follows, with a special rule for the dimensions of a type:

replaceable type T=Real[2] constrainedby Real; replaceable Real[2] x constrainedby Real;

This is inconsistent and contradictory language design and is a prime example of a rule that makes the language hard to understand and learn.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1247

[modelica-trac-importer]

Comment by hansolsson on 24 Sep 2013 10:18 UTC Language group: Would require a grammar change for constrainedby Real[:]. It becomes complex if the dimension is not required on constrainedby, and incompatible if required on constrainedby. It would also allow you to define a dimensions as changeable with a default by making the component replaceable which seems like a new awkward way (currently it is possible by using a parameter for dimension which is also awkward).

The conclusion is that a more complete redesign is needed and not clear. Postpone.

[adrpo]

Having dimensions in the constrainedby seems necessary. For example I've seen something weird like this:

replaceable IBPSA.Fluid.MixingVolumes.BaseClasses.MixingVolumeHeatPort vol[nEle]
    constrainedby IBPSA.Fluid.MixingVolumes.BaseClasses.MixingVolumeHeatPort(
    redeclare each package Medium = Medium,
    each energyDynamics=Modelica.Fluid.Types.Dynamics.FixedInitial,
    final initialize_p={(i == 1 and not Medium.singleState) for i in 1:nEle},
    each m_flow_nominal=1,
    each V=1,
    each nPorts=2) "Mixing volume";

which is quite wrong as you have array modifiers on a non array class in constrainedby, but Dymola accepts it fine. It would be correct if written as:

replaceable IBPSA.Fluid.MixingVolumes.BaseClasses.MixingVolumeHeatPort vol[nEle]
    constrainedby IBPSA.Fluid.MixingVolumes.BaseClasses.MixingVolumeHeatPort[nEle](
    redeclare each package Medium = Medium,
    each energyDynamics=Modelica.Fluid.Types.Dynamics.FixedInitial,
    final initialize_p={(i == 1 and not Medium.singleState) for i in 1:nEle},
    each m_flow_nominal=1,
    each V=1,
    each nPorts=2) "Mixing volume";

Currently the only way to deal with this properly is using a short class definition:

model T = IBPSA.Fluid.MixingVolumes.BaseClasses.MixingVolumeHeatPort[nEle];

replaceable T vol
    constrainedby T(
    redeclare each package Medium = Medium,
    each energyDynamics=Modelica.Fluid.Types.Dynamics.FixedInitial,
    final initialize_p={(i == 1 and not Medium.singleState) for i in 1:nEle},
    each m_flow_nominal=1,
    each V=1,
    each nPorts=2) "Mixing volume";