"output_expression_list" does not make sense in the definition of primary

[modelica-trac-importer]

Reported by Teemu Lempinen on 28 Feb 2013 08:41 UTC We noticed that expressions like the following are valid in Modelica syntax:

"(,,,,)^(,,,,)"

The definition of primary has the option "(" output_expression_list ")" which, to us, does not make sense.

primary :
UNSIGNED_NUMBER
 | STRING
 | false
 | true
 | ( name | der | initial) function_call_args
 | component_reference
 | "(" output_expression_list ")"
 | "[" expression_list { ";" expression_list } "]"
 | "{" function_arguments "}"
 | end

As far as we know, the only place where output_expression_list is needed is in statements:

statement :
( component_reference ( ":=" expression | function_call_args )
| "(" output_expression_list ")" ":=" component_reference function_call_args
|...

Is there a reason for output_expression_list in primary or is it an error in the specification?

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1005

[modelica-trac-importer]

Comment by sjoelund.se on 28 Feb 2013 08:46 UTC It can also be used on the left side of any equation (which unlike statements is not limited to only crefs or output list).

[modelica-trac-importer]

Comment by hansolsson on 28 Feb 2013 08:54 UTC And building on Sjölund's answer: this allows the grammar to be useful with tools relying on LL-k parser-generators for the case: (a.b.c... Instead there is then a semantic restriction for where to use output_expression_list.

So: Yes, there is a reason. (Although not a really good one.)

[modelica-trac-importer]

Modified by dietmarw on 28 Feb 2013 08:56 UTC

[modelica-trac-importer]

Comment by Teemu Lempinen on 28 Feb 2013 08:59 UTC With the help of Sjölund and Pop at OpenModelica forum, I was able to come up with this example. It displays a use for output_expression_list.

model Test

function func
 input Real a;
 input Real b;
 output Real c;
 output Real d;
algorithm
 c := a*a;
 d := b+b;
end func;

 parameter Real e = 3;
 parameter Real f = 5;
 Real g;
equation
 (,g) = func(e,f);
end Test;

Sorry for the unnecessary ticket, I have been enlightened :)

[modelica-trac-importer]

Comment by dietmarw on 28 Feb 2013 09:00 UTC No damage done :-)

[modelica-trac-importer]

Comment by stefanv on 28 Feb 2013 14:50 UTC I realize the ticket is closed, but will add my comment. The problem here is that "(" output_expression_list ")" is being used both to describe an output-expression-list (i.e., that multi-part thing that can appear on the LHS of an "=" or ":="), and also just an arbitrary parenthesized sub-expression.

If the current "(" output_expression_list ")" were removed from the grammar (and no other changes made), then the following expression would be syntactically invalid: a = (b + c) * d.

From a human readability point of view, primary should contain "(" expression ")", and "(" output_expression_list ")" should appear only in the places where it is allowed. Unfortunately, that would make it difficult for a parser generator to handle.

[modelica-trac-importer]

Comment by jmattsson on 28 Feb 2013 15:02 UTC The grammar in the specification does not necessarily need to be exactly the same as the one fed to a parser generator. I think it would be better to describe the language as cleanly as possible, and let the tool vendors that need a LL(n) parser make such adjustments themselves. The specification doesn't state that such-and-such error must be detected in the parser - only what is legal Modelica.