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

[HansOlsson]

During the conference we got feedback that the grammar is ambiguous.

I understand that the problem is due to trying to make the grammar more logical - but:

• We should be consistent; so that equations and statements are treated in a similar way.
• We might as well explain it - people familiar with parsers should just be able to read the grammar.

[HansOlsson]

We could also add:
Similarly if output-expression-list is not merely an expression it is only allowed in statement as explicitly given and in equation-or-procedure matching "(" output-expression-list ")" = component-reference function-call-args

[henrikt-ma]

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}

[HansOlsson]

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.

[henrikt-ma]

I am not against rewriting the production rules per se, but I'd like to hear exactly which ambiguity that was reported during the conference?