Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semantics of function call equations and statements #3632

Open
henrikt-ma opened this issue Dec 20, 2024 · 4 comments
Open

Semantics of function call equations and statements #3632

henrikt-ma opened this issue Dec 20, 2024 · 4 comments
Labels
clarification Specification of feature is unclear, but not incorrect

Comments

@henrikt-ma
Copy link
Collaborator

henrikt-ma commented Dec 20, 2024

Isn't the specification missing some sections giving semantics of equations and statements in the following form?

f(args);

For example, I can find the type rule for a simple equality equation in 8.3.1, but where is the type rule for the equation above?

I suppose a record constructor can never be used in this form, since the record constructor should be seen as a function with a single output for purposes of these rules (they are sometimes not seen as just a function with a single output, but is see no reason to make such an exception here).

Speaking of record constructors, is this a valid way to ignore a constructed record value (which is syntactically in the correct form for ignoring all outputs of a function call)?

() := R(1.0);
@HansOlsson
Copy link
Collaborator

Isn't the specification missing some sections giving semantics of equations and statements in the following form?

f(args);

It could be made clearer, but https://specification.modelica.org/master/functions.html#function-call specify how function call works, before considering the outputs, so it should still apply.

It is included as the last item in https://specification.modelica.org/master/equations.html#equations-in-equation-sections

For specific semantics, https://specification.modelica.org/master/functions.html#pure-modelica-functions state that the function is assumed to have side-effects and/or asserts, so that it cannot just be ignored. The possibility of asserts (which are allowed even for a pure function) mean that we cannot totally remove such a call, but can reduce the number of calls (if it is pure).

For example, I can find the type rule for a simple equality equation in 8.3.1, but where is the type rule for the equation above?

Since there is no equality I don't see why we need a type rule in this case (or specifically what the type should should say). However, for overview it could be that we should have a subsection for them including https://specification.modelica.org/master/equations.html#reinit etc

Speaking of record constructors, is this a valid way to ignore a constructed record value (which is syntactically in the correct form for ignoring all outputs of a function call)?

() := R(1.0);

I don't see a problem with that, but I don't see much use either, since a record constructor is pure. So the only reason would be to trigger an automatically generated assertion based on some potential mismatch of sizes for the inputs.

@HansOlsson HansOlsson added the clarification Specification of feature is unclear, but not incorrect label Jan 8, 2025
@HansOlsson
Copy link
Collaborator

I don't see that any additional text is needed based on the above.

@henrikt-ma
Copy link
Collaborator Author

However, for overview it could be that we should have a subsection for them including https://specification.modelica.org/master/equations.html#reinit etc

Sounds like a good plan to me (with symmetric treatment of statements, of course).

@henrikt-ma
Copy link
Collaborator Author

Speaking of record constructors, is this a valid way to ignore a constructed record value (which is syntactically in the correct form for ignoring all outputs of a function call)?

() := R(1.0);

I don't see a problem with that, but I don't see much use either, since a record constructor is pure. So the only reason would be to trigger an automatically generated assertion based on some potential mismatch of sizes for the inputs.

Agreed. Admittedly, this part deviated a bit from the central topic here. The main point was to conclude that a record constructor cannot be used in the component-reference function-call-args since it is a function returning one value, and that there should be a rule in the (still missing) section for the component-reference function-call-args form saying that the function called shall have no outputs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Specification of feature is unclear, but not incorrect
Projects
None yet
Development

No branches or pull requests

2 participants