I added an optional attribute "argumentValue" to "Identifier" that should be used when the identifier is used for a binding expression in a function call´s argument... ok?

I suppose you are talking about FunctionEquationsSet (correct me if I'm wrong, but I can't find FunctionSetCall). The screenshot is in attach. The goal is to represent the dynamic equations due to user-defined functions like (x,y)=f(v,u) as you guessed. It should be interpret like a new equation for every ScalarOutput element in the document. If you have better ideas, you're welcome.

According to the theorem of Bohm-Jacopini, every algorithm can be represented using only one sequence,choice and loop structures.

Assuming of having vectors, using my solution, a possible translation could be:

x[0]=1; x[1]=-4; x[2]=34; x[3]=4;
for i=0 to 3
......... do something with x[i] ..........
end for

Sorry, I should write a better documentation. I think we don't need to modify the schema: the signature of the function shows the list of the outputs and inputs. When we use FunctionCall in an expression, it doesn't ask any information about output variables, because it assumes that the function returns only one value.This value could be either the only value returned by the function OR the first value if the function returns several outputs.

QUESTION: I've embedded the derivative/inverse functions in the "root" function definition. Another solution would be to define the derivatives externally and use an attribute as an "annotation" to recall that it is a derivative/inverse function of another one, previously defined. What do you prefer?

I added an optional attribute "argumentValue" to "Identifier" that should be used when the identifier is used for a binding expression in a function call´s argument... ok?

Yes, binding for input and outputs has been already improved and what I was talking about there is the arguments of function calls. Actually the solution of having just an attribute to bind a value to the identifier is not enough, because attributes can belong to simple types only (and we need also expressions). I will fix this.

I modified the For loop definition. Please take a look to the image in attach.

The index is now composed by an attribute "IteratingVariable" that should hold the name of the variable in the index, while an optional "IterationSet" element of type Exp has been added to represent the set where the variable should iterate. Is it ok like this? Suggestions? Is the IterationSet definition a bit ambiguous?

[img_assist|nid=217|title=ForLoop with IterationSet|desc=|link=none|align=left|width=640|height=255]

I suggest to keep this for now (it works + it's easy) and then I will try to design a better solution for the iteration variable later.

Some issues about the XML code generation of Functions.

The model I'm simulating is the following:

-------------------------------------------------------------------
package myPack
model myModel

function f
input Real x[2];
output Real y[2]={28,91};
algorithm
y:=x;
end f;

Real z[2]={1,1};
Real w[2];

equation
w=f(z);

end myModel;

end myPack;
------------------------------------------------------------------

1) The FUNCTION NAME is represented like this
< fun:Function name="myPack.myModel.f">

Would it be better to have just "f" or is it ok like this?

2) About the VARIABLES TYPE. The code generated for the input variable x is

< fun:InputVariable name="x" type="Real[2]" xsi:nil="true"/>

Is it ok to represent the type in this way? Or it would better to have type="Real" and another attribute that says it is an array? I'm thinking of which one is the best solution to have an easier import of the model.

3) VARIABLES INITIAL VALUES. The code generated for "output Real y[2]={28,91};" is just:

< fun:OutputVariable name="y" type="Real[2]" xsi:nil="true"/>

where nil="true" means that there is no initial value. It seems like there is no initial value represented in the AST, but the binding of the variable and initial values (y[1]:=28, y[2]:=91) are made at the beginning of the algorithm section as assignment nodes. It is perhaps logically correct, but I'm guessing if it is the result you wanted while designing the AST.

4) FLATTENED VARIABLES. Representing the assignment y:=x in the algorithm, the result I have is

< fun:Assign>
< exp:Identifier>y< /exp:Identifier>
< fun:Expression>
< exp:Identifier>x< /exp:Identifier>
< /fun:Expression>
< /fun:Assign>
< fun:Assign>
< exp:Identifier>y< /exp:Identifier>
< fun:Expression>
< exp:Identifier>x< /exp:Identifier>
< /fun:Expression>
< /fun:Assign>

So the reference to the index of the array generating the variable is missing. I used FIdUse.name() to get the name of the variable (and I have the correct result when they are used in equations). What's wrong?

I'm generating code for the algorithm

if (x[1]==y[1]) then
x:=y;
end if;

I figured out that an else branch is always produced. Taking a look at the grammar, in fact, I noticed

FIfStmt : FIfWhenStmt ::= ElseStmt:FStatement*;

Why? ElseStmt should be completely optional, shouldn't it? (Modelica specification, par.11.2.6)

Yes, the problem was that an else node was always generated, but I've found the error, that it was in code generation, not in the grammar. Sorry!

mmmh, thinking about this, I'm still not sure. There is difference between having a list of statements with no statements and not having a list. It is the same difference between

if(expression) then
....list of statements....
else
.... nothing ....
end if;

and

if(expression) then
.... list of statements ...
end if;

in fact in the code generation the condition I have to solve is

if (this.getNumElseStmt()!=0){
... generate code for else statement
}

so I can't generate correct code for the first case. But it's just details I think

The element OutputVariable (such as Input and Protected) are defined by an expression and attributes name and type, like this:

< fun:OutputVariable name="name" type="Real" >
< exp:RealLiteral>1.2< /exp:RealLiteral>
< /fun:OutputVariable>

if the expression doesn't exist, then the element has nil value (notice that this attribute is not defined in the schema, but it is proper of XML schema language), represented by that attribute. I've used it to have a more compact code, because this allows to have the short tag representation (one line, as < element /> instead of < element>< /element>:

< fun:OutputVariable name="name" type="Real" nil="true"/>

The alternative is to explicitly create an optional element "BindingExpression" or "InitialExpression" and always have

< fun:OutputVariable name="name" type="Real" >
< fun:BindingExp>
< exp:RealLiteral>1.2< /exp:RealLiteral>
< /fun:BindingExp>
< /fun:OutputVariable>

or, if there is no expression:

< fun:OutputVariable name="name" type="Real" >< /fun:OutputVariable>

It is a matter of design: we can choose the solution we prefer: just tell me what you think...

So, I've got your idea, a solution for "input Real x[2];" could be:

< fun:InputVariable name="x[2]" type="Real" > .....

or do you intend something else?

currently the INDEX of the for loop is designed like this:

< fun:Index IterationVariable = "i" >
< fun:IterationSet>
< exp: an expression >....
< /fun:IterationSet>
< /fun:Index>

for example the code
-------------------------
for i in {1,5} loop
end loop;
------------------------

produces

< fun:For>
< fun:Index IterationVariable="i">
< fun:IterationSet>
< exp:Array>
< exp:IntegerLiteral>1< /exp:IntegerLiteral>
< exp:IntegerLiteral>5< /exp:IntegerLiteral>
< /exp:Array>
< /fun:IterationSet>
< /fun:Index>
< fun:Statements>....

But how loops like

for i in 1:4 loop
end loop;

are represented in the AST ? I generate the code from:

FForIndex : CommonForIndex ::= FVariable;
abstract CommonForIndex ::= [FExp];

Solved, thank you

It can be implicit if you are talking about XML language (document well-formed), not XML Schema language. If an element is designed as "nillable" in the schema, it must have the attribute nil if it has no value, otherwise it isn´t validated. Notice the expression is NOT an element inside the OutputVariable element, but it is the content of the variable itself (i.e. the variable is defined as expression + some attributes). The alternative is to create an optional expression element, say "BindingExpression", inside OutputVariable

It could be. Or another solution can be to add to the schema a new expression exp:EmptyExp ... What do you think? Johan?

1f) The function call statement is defined like this:

FFunctionCallStmt : FStatement ::= Left:FFunctionCallLeft* Call:FAbstractFunctionCall;

FFunctionCallLeft ::= [FExp];

but I noticed that if the left part is composed by more expressions, they are enclosed in only one vector expression: is it correct? If it is, why Left is defined as a list of FFunctionCallLeft?

2f) currently the left part is represented in the schema by an element of string type (that is supposed to be the identifier of the variable). Is it better to have it as expressions? As an array? Or would it be too ambiguous? This modify can be applied not only in the function call statements (inside the algorithms of the functions), but also to the equations produced by function calls.

3f) always regarding the left part, maybe having an empty expression could be useful in this case to represent cases like (a, ,c) = f(x)

As you correctly said "To start with, note that this is not a vector expression, it is a list of variables receiving return values from the function". It is exactly for this reason that it is not necessary (and I think it is wrong) to represent the returned value as an Exp. If you say so it is better a list of < exp:Identifier> or merely a list of elements of type string representing the resulting variable.

If we don't want to have equations (FFunctionCall) like x+2 = f(x) or sin(x) = f(x) it's more clear to have just a list of identifiers.

Notice, Jesper, that my goal is not to export documents and have schema in a way that bestly fit with JModelica's grammar, but that is most general as possible, so i think it's better to avoid VALID documents with the previous kind of equations.

In fact I talked about a list of identifiers, not of a "single identifier" and your model is not a counterexample for my solution, but the contrary.

< FunctionCallEquation>
< OutputVariable> x[1] < /OutputVariable>
< OutputVariable> x[2] < /OutputVariable>
< SourceFunction name = "M.F">
< Arguments>< < /Arguments>
< /SourceFunction>
< /FunctionCallEquation>

Where this has to be considered as 2 different equations, one for each output variable.

PS: notice that there is no record support in my project.

I see your point and it is a tricky problem. I can try to find a solution for the representation of names, but for sure it will complicate the schema.

A question: is this kind of notation necessary also in the equation part or just in the algorithms? I mean, when we are using variables in the equation section, the index has no reason to be evaluated as an expression, right?

They are represented by another element "BindingExpression" for the parameters. Yes, we should use the same mechanism. I've just tried to limit the number of nodes, but you're right, maybe this is still the preferable solution.

Yes, you're right. I didn't think about this "grouping problem". Yes, the idea to have either identifier or array of identifiers is feasible and better than allowing more general expressions.

At this point I'd add a third possible choice, to represent the empty outuput arguments, say < EmptyOutputArgument>

Good observation, but I don't think they necessarily should be allowed: it is always possible to produce just one long array from an array of array. It's a restriction that could be applied on the scalarization algorithm and a matter of design. How has it been implemented in JModelica? Johan, what do you think about this: should we or should we not have recursive array of identifiers? (it is not a problem to design in this in the schema, anyway, but just a choice). In my opinion having just one array allows an easier import, especially of the FunctionCallEquations

It's because you are thinking to the Modelica representation, while my schema is the representation of a mathematical model, a DAE, not of a Modelica model. Real[2,2] and Real[4] produce a set of the same 4 equations, but the second one (without recursion)is a more clear representation for the equations set and it's easier to import and understand. It's always better to avoid more complex data structures in this case, because the meaning is always a SET of equations like scalarvariable = functioncall....

It is possible to differentiate in my schema the function calls relative to the FunctionCallEquations and the ones inside the algorithms of user-defined functions, allowing this kind of recursion only in the second case. I think it's a better way.

Yes, that's the source of the misunderstanding between me and Jesper. At the beginning of the project we supposed full scalarization and ordering of the variables. I see your point now, but I need the feedback of prof. Casella on this, because he doesn't agree I will never have my master :)