Resolving name conflict in component name and type

[eshmoylova]

How should scoping be done when a name of a component conflicts with the name used in a type specification? Consider the following example.

package SameName
  model A
    Real x;
  equation 
    x = time;
  end A;
end SameName;

model B
  SameName.A SameName;
  Real x;
equation 
  x = SameName.x;
end B;

Should it give an error or should a compiler find the correct definition for SameName when resolving the type of B.SameName?

What if the conflict is not in the same component but in different?

model C
  SameName.A x;
  Real SameName;
equation 
  x.x = SameName;
end C;

What if the order of the declaration of x and SameName swapped?

model D
  Real SameName;
  SameName.A x;
equation 
  x.x = SameName;
end D;

To me, it looks like in model B there is a cyclic definition of the component SameName. We are supposed to resolve SameName.A in the scope of B, and looking up SameName we would find B.SameName. I tried it in different tools and got different results. Some tools find the package SameName others fail with not very clear messages. Trying to improve on the unclear messages, I find that I cannot just screen for cyclic definitions because then I get into problems like models C and D where the result is different depending on the order of declarations, which should not happen.

There was a similar issue #1170, which resulted in the change to the specification in Section 4.2 saying:
"A component shall not have the same name as its type specifier."

But it looks like the case when only the first name in the type specifier is the same as the component's name manages to sneak around that rule. Also it does not cover the cases of models C and D.

[qlambert-pro]

I think Section 5.3.2 is helpful here. Because in all these cases we find a component for the first identifier, the second bullet point applies. WSM rejects all these models on the basis that it is not possible to find a class declaration by looking exclusively at component elements.

[HansOlsson]

I think Section 5.3.2 is helpful here. Because in all these cases we find a component for the first identifier, the second bullet point applies. WSM rejects all these models on the basis that it is not possible to find a class declaration by looking exclusively at component elements.

I would agree with this - and I also believe that the statement in 4.2 is oddly placed, and should be generalized to handle this.

[eshmoylova]

I think Section 5.3.2 is helpful here. Because in all these cases we find a component for the first identifier, the second bullet point applies. WSM rejects all these models on the basis that it is not possible to find a class declaration by looking exclusively at component elements.

I like this. In MapleSim we first find the specified type and then check that it is a class, which in the case of models B and C we cannot. The way you do it short-cuts the type resolution. What do you say in the error message? Is it clear that SameName.A is assumed to be B.SameName.A and not the global SameName.A?

There is one more question though. When looking up SameName.A we find a local component called SameName and know that SameName.A in this case cannot be a class should we give up and throw an error or look for any other definition of SameName? The reason I am asking is because I tried these examples in Dymola (2018). The models B and C pass and the package SameName is found. Model D fails. @HansOlsson?

[qlambert-pro]

This is the error we give:

Error: B [2:3-2:3] Invalid lookup. When looking up SameName.A in scope B, SameName is expected to be a class but it is found to be a component.

The way we make it clear which SameName we are referring to is by having the name be a hyperlink to the definition.

[perost]

OpenModelica rejects all three models with a similar error:

Error: Class name 'SameName.A' was found via a component (only component and function call names may be accessed in this way).

We never backtrack during name lookup, once the first identifier has been found we won't try to find it anywhere else if the lookup of the rest of the name fails for some reason.

[HansOlsson]

I agree that they should all fail in the same way. We will update Dymola for this.

[eshmoylova]

I think Section 5.3.2 is helpful here. Because in all these cases we find a component for the first identifier, the second bullet point applies. WSM rejects all these models on the basis that it is not possible to find a class declaration by looking exclusively at component elements.

I would agree with this - and I also believe that the statement in 4.2 is oddly placed, and should be generalized to handle this.

The problem I reported is fully answered. I could close the issue but there is the above comment by @HansOlsson about updating the statement "A component shall not have the same name as its type specifier" in 4.2. Should we keep this issue open to update that statement? Or create a separate issue? Or is it not necessary because 5.3.2 covers the general case better?

[HansOlsson]

I would propose to update 4.2 from
"A component shall not have the same name as its type specifier"
to
"A component shall not have the same name as its type specifier or first identifier of a composite type specifier, see section 5.3.2."
or by stating purpose:
"The lookup of the type of a component shall not be influenced by the component declaration itself, and thus the component name may neither be the same as its type specifier nor to the first identifier of a composite type specifier, see section 5.3.2."

[HansOlsson]

Henrik: Shall be clear restriction on name - not lookup.

• Simpler solution - just remove it. Henrik, Adrian, Gerd, Christoff, Markus, Martin, Dag
• "The name of component declaration shall not be such that it influences the lookup of the component itself, and thus the component name may neither be the same as its type specifier nor to the first identifier of a composite type specifier, see section 5.3.2." as non-normative Quentin, Axel, Stefan
  Hans abstain

1st option.

And Add example in 5.3.2.