Use of a component parameter as a value is currently not supported.

Use of a component parameter as a value is currently not supported.

The folowing CIF model generates this error:

group def A():
  alg int var1 = 1;
  alg int var2 = 2;
end

group def B(A a):
  alg int x = a.var1;
  alg int y = x + a.var2;
end

group def C(A a):
  b: B(a);
end

a: A();
c: C(a);

While you could rewrite the model as follows, it becomes less clean (and less adaptable once the model of A grows).

group def A():
  alg int var1 = 1;
  alg int var2 = 2;
end

group def B(alg int var1, var2):
  alg int x = var1;
  alg int y = x + var2;
end

group def C(A a):
  b: B(a.var1, a.var2);
end

a: A();
c: C(a);

added CIF TypeEnhancement labels

The ElimComponentDefInst transformation leans quite heavily on the assumption that CompParamWrapExpression's and CompParamWrapType's can only be filled in by CompInstWrapExpression's and CompInstWrapType's, respectively. I would assume that changing that is quite complex.

On the other hand, in this example, it doesn't seem too difficult. In the first elimination round, the a.var in alg int x = a.var1 changes from a CompParamWrapExpression with the parameter being a from B to a CompParamWrapExpression with the parameter being a from C. In the second elimination round, the CompParamWrapExpression a.var is replaced by the concrete variable a.var.

You also know that when you eliminate a ComponentInst (named A) that has as an actual value a CompParamWrapExpression that CompParamWrapExpression is not eliminated in the same round. As the definition where the CompParamWrapExpression is part of, still contains A.

@ddennis do you know any reasons why this isn't supported, aside from complexity?

When we first added component definition/instantiation, we had difficulties implementing it correctly, if I remember it right. I imagine we kept it simple then, introducing some restrictions to keep things manageable. We now have a better grip on things, and we fixed #25 (closed) and #66 (closed) a while back.

However, I do think the elimination of component definition/instantiation is still somewhat complex. So changing this may not be trivial. And not just the elimination needs to be updated, but also the type checker and various things in the cif.common project. It is all non-trivial to get this correct. But I agree it should be doable these days.

I see that the error has the following comment:

// Unsupported, for now (can't represent this in metamodel).

We have ComponentExpression but I think that is only for references to automata, groups and component instantiations. We have CompParamWrapExpression but that is only for references via a component parameter, not references to the component parameter itself. I think we would need a CompParamExpression then. I don't think it makes sense to allow ComponentExpression to refer to component parameters, as a ComponentExpression must have a ComponentType I think, while here we have a ComponentDefType. But I may be wrong here, as it's been a while since I looked into all this in detail.

Yes, you are right, ComponentExpression's have a ComponentType, whereas here we have/want a ComponentDefType.

I will add the following extension to the metamodel. Fully in line with your suggestion.

The proposed extension makes sense to me.

Yes, I like it as well.

changed milestone to %v0.4

assigned to @freijnen

@ddennis I think I got this working. How should I commit it? Metamodel and type checker as one Merge Request and adaptions to ElimComponentDefInst as a separate Merge Request?

If the separate merge requests can actually be merged to develop separately then it may help to have separate merge requests. If there is a lot of overlap in the merge requests it can help to review them separately, and they can be merged separately either to develop or a temporary integration branch like for the 'svgin assign input variables' issue. But if the separate things don't make sense without the other changes and the changes are in different files, then it may make more sense to just use one branch and one merge request. It sounds like this is an instance of the latter, but you can probably judge that better.

I would also expect changes in the cif.common plugin.

created branch 222-use-of-a-component-parameter-as-a-value-is-currently-not-supported to address this issue

mentioned in commit f426b286

mentioned in commit ff0548e5

mentioned in commit 3edc4e6d

mentioned in commit 7f723ab9

mentioned in merge request !200 (merged)

mentioned in commit 10dac387

mentioned in commit cf5a6108

mentioned in commit fba50279

mentioned in commit 1663aec3

mentioned in commit 67d0c487

mentioned in issue #244 (closed)

mentioned in commit a539f433