Lookup issue with NF and weird error message

[Francesco Casella]

Please consider the following test case (also attached)

package TestOuter

partial model PartialFluid
  constant Real c = 1;
  partial function fBase
    input Real u;
    output Real y;
  end fBase;
end PartialFluid;

model MyFluid
  extends PartialFluid;
  function f
    extends fBase;
  algorithm
    y := 3*u;
  end f;
end MyFluid;

model System
  replaceable model FluidModel = MyFluid constrainedby PartialFluid;
  FluidModel fluid;
end System;

model Component
  outer System system;
  Real a = system.fluid.f(3);
end Component;

model Model
  Component c;
  inner System system;
end Model;

end TestOuter;

Instantiating TestOuter.Model returns

[1] 11:36:06 Scripting Error
Internal error: no tokens left to replace %s with. 
Given message was: Illegal access of class 'f' via component 'system.fluid.f' when looking for '%s'. 


[2] 11:36:06 Translation Error
[TestOuter: 27:3-27:29]: 

This looks like a bug with a pretty low-level error reporting - I don't have the foggiest clue what %s stands for, but I guess you do :)

[Per Östlund]

Replying to casella:

This looks like a bug with a pretty low-level error reporting - I don't have the foggiest clue what %s stands for, but I guess you do :)

The error messages are written as templates with %s as placeholders for the actual strings. In this case the error message was called with too few arguments, so there was no argument left to substitute the last %s with.

For this particular error it's the second argument that's missing, i.e. the component name (system.fluid.f is the name being looked for). Unfortunately that information is not actually available at the point where the error is generated, so I'll need to think about what the best solution would be in this case.

[Per Östlund]

For the record, I only consider the issue to be that the error message isn't output correctly. The error message itself is correct.

[Francesco Casella]

Replying to perost:

For the record, I only consider the issue to be that the error message isn't output correctly. The error message itself is correct.

I read Section 5.3.2 of the spec many times, and I thought this model was valid. BTW, both the old FE and Dymola 2018 accept it without problems. Now that I look better, I see the clause "All identifiers of the rest of the name (e.g., B and B.C] must be classes". I guess this is the reason why this model is invalid, i.e., that B in this case is not a class but a component. Did I get this right?

BTW, I miss the reason of all these restrictions in accessing and using class names from instantiated components. From a modelling point of view, this would be very convenient, particularly through inner/outer access to a system object. Many tools (including OMC with the old FE) implement laxer rules apparently without problems. Are there potentential negative issues in being more tolerant that I don't see?

[Per Östlund]

Replying to casella:

Replying to perost:

For the record, I only consider the issue to be that the error message isn't output correctly. The error message itself is correct.

I read Section 5.3.2 of the spec many times, and I thought this model was valid. BTW, both the old FE and Dymola 2018 accept it without problems. Now that I look better, I see the clause "All identifiers of the rest of the name (e.g., B and B.C] must be classes". I guess this is the reason why this model is invalid, i.e., that B in this case is not a class but a component. Did I get this right?

Yes, that's right. The old FE didn't check such restrictions at all, simply because the lookup was too complicated.

BTW, I miss the reason of all these restrictions in accessing and using class names from instantiated components. From a modelling point of view, this would be very convenient, particularly through inner/outer access to a system object. Many tools (including OMC with the old FE) implement laxer rules apparently without problems. Are there potentential negative issues in being more tolerant that I don't see?

In the NF I don't think there are any particular issues with allowing it, at least the given model works just fine in that case. But I don't know the reason behind that particular restriction either.

[Francesco Casella]

It was just a question, if we should push to lift this restriction for Modelica 3.5, but as of today we should of course follow the spec in force.

BTW, TestOuter2.Model works fine

package TestOuter2

partial model PartialFluid
  constant Real c = 1;
  partial function fBase
    input Real u;
    output Real y;
  end fBase;
end PartialFluid;

model MyFluid
  extends PartialFluid;
  function f
    extends fBase;
  algorithm
    y := 3*u;
  end f;
end MyFluid;

model System
  replaceable model FluidModel = MyFluid constrainedby PartialFluid;
end System;

model Component
  outer System system;
  Real a = system.FluidModel.f(3);
end Component;

model Model
  Component c;
  inner System system;
end Model;

end TestOuter2;

[Adrian Pop]

We could allow it with a warning: "Components found on the path to ....".

[Per Östlund]

Well, the error message is fixed in 155a040 at least. I just replaced the "via component %s" with "via a component".

Replying to adrpo:

We could allow it with a warning: "Components found on the path to ....".

That could lead to a whole lot of warning if someone would use it. I haven't seen any libraries that use this though, so I'm inclined to just leave it as it is. If someone wants it to be allowed I'd suggest taking the discussion to the Modelica trac. If it turns out that there's no particular reason for the restriction and most tools allow it we can probably remove the restriction completely.