Skip to content

Make the grammar more consistent, and explain rewrite based on feedback. #3757

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.

Sign up for GitHub

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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Make the grammar more consistent, and explain rewrite based on feedback. #3757

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
4f2938e
Make the grammar more consistent, and explain rewrite based on feedback.
HansOlsson Oct 7, 2025
bbb5e88
Nonnormative
HansOlsson Oct 7, 2025
7499e04
AddWS
HansOlsson Oct 7, 2025
9d36ba5
Update chapters/syntax.tex
HansOlsson Oct 14, 2025
26c30d9
Apply suggestions from code review
HansOlsson Oct 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 25 additions & 4 deletions chapters/syntax.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -258,7 +258,7 @@ \subsection{Modification}\label{modification}


\subsection{Equations}\label{equations1}

See below for how to rewrite two rules for recursive descent parsers.
\begin{lstlisting}[language=grammar]
equation-section :
[ initial ] equation { some-equation ";" }
Expand All @@ -267,17 +267,20 @@ \subsection{Equations}\label{equations1}
[ initial ] algorithm { statement ";" }

some-equation :
( simple-expression "=" expression
( equation-or-procedure
| if-equation
| for-equation
| connect-equation
| when-equation
| component-reference function-call-args
)
description

equation-or-procedure :
simple-expression "=" expression
| component-reference function-call-args

statement :
( component-reference ( ":=" expression | function-call-args )
( statement-or-procedure
| "(" output-expression-list ")" ":="
component-reference function-call-args
| break
Expand All @@ -289,6 +292,10 @@ \subsection{Equations}\label{equations1}
)
description

statement-or-procedure :
component-reference ":=" expression function-call-args
| component-reference function-call-args

if-equation :
if expression then
{ some-equation ";" }
Expand Down Expand Up @@ -352,6 +359,20 @@ \subsection{Equations}\label{equations1}
connect "(" component-reference "," component-reference ")"
\end{lstlisting}

\begin{nonnormative}
The given constructs equation-or-procedure and statement-or-procedure are not suitable for recursive descent parsers.

A work-around is to use the following syntax with semantic checks to ensure that only the grammar above is accepted.

\begin{lstlisting}[language=grammar]
equation-or-procedure :
simple-expression ( "=" expression | function-call-args )

statement-or-procedure :
component-reference ( ":=" expression | function-call-args )
\end{lstlisting}
\end{nonnormative}

Comment on lines 362 to 375
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must say that I am actually sceptic about the idea of this non-normative section altogether. I generally don't expect Modelica parsers to be implemented exactly as presented in this chapter, as other formulations are better suited for more user-friendly parsing error messages.

I would expect that those working with recursive descent parsers will be able to figure out how to write their parsers, just like those using any other parsing technique.

I also see a risk that having these rules in the non-normative section will still add confusion to the reader who is not paying attention to the non-normative nature of these rules.

Suggested change
\begin{nonnormative}
The given constructs equation-or-procedure and statement-or-procedure are not suitable for recursive descent parsers.
A work-around is to use the following syntax with semantic checks to ensure that only the grammar above is accepted.
\begin{lstlisting}[language=grammar]
equation-or-procedure :
simple-expression ( "=" expression | function-call-args )
statement-or-procedure :
component-reference ( ":=" expression | function-call-args )
\end{lstlisting}
\end{nonnormative}

Copy link
Collaborator Author

@HansOlsson HansOlsson Oct 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thoughts:

  • The current specification is problematic with two different ways to handle the same issue.
  • There were complaints for the grammar, and I think the non-normative text would help with that. I basically see a clear benefit in making it easy for others to make a parser for the Modelica language, and giving a clear direction for it; and no real down-sides. Since the construct was used previously, it also helps with demonstrating a sense of backwards compatibility.
  • There are still odd constructs in the grammar due to it being recursive-descent oriented.

Specifically the complaints was about diagnostics for the incorrect equation foo()=;

Or in summary, I don't see the problem with the non-normative section above, if people just add the productions from the non-normative text to their grammar without reading the text they will have a grammar with duplicate productions - and they should then realize the problem.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • There are still odd constructs in the grammar due to it being recursive-descent oriented.

Yes, and this is one of the reasons why I don't think one should expect implementations to use the given grammar as-is.

Starting to move away from recursive-descent orientation sounds like a good idea to me, as I think that this could result in a grammar which is easier for a human to decipher. However, if that is the plan, I really don't want to have non-normative explanations all over the place with alternative production rules for those with alternative parsing mindsets.

Or in summary, I don't see the problem with the non-normative section above, if people just add the productions from the non-normative text to their grammar without reading the text they will have a grammar with duplicate productions - and they should then realize the problem.

I don't imagine a problem for those who actually implement the grammar, but for the reader who is just trying to understand the grammatical structure of the language. For this reader, I think the chapter will be more helpful without additional production rules in non-normative sections.

\subsection{Expressions}\label{expressions1}

\begin{lstlisting}[language=grammar]
Expand Down