Semantik-noteringar	-*- outline -*-

* redeclare extends

What does "redeclare extends ..." mean? It is not explained in the
report. I guess it is provided as a means to alter modifications in
extends claueses, but I can't see the need.

	class A
	  Real x;
	end A;

	class B
	  extends A(x=17);
	end B;

	class C
	  B b(redeclare extends A(x=100));
	end C;

The class C could just as easy be written as

	class C
	  B b(x=100);
	end C;

The only time I can find any difference between these two forms is
when the programmer forgot about the variable shadowing rules.

	class A
	  Real x;
	end A;

	class B
	  Integer x = 1;
	  extends A;
	end B;

	class C
	  B b1(redeclare extends A(x=100));
	  B b2(x = 100);
	end C;

In this case b1.x will be 1 and b2.x will be 100, but the modification
of b1 is lost, so I can't see the need for it.

Status: This seems to be actually needed.

* Types in equations

Vilka variabler fr man ha i ekvationer? Bara Real(Type) och
Integer(type)?

Hur hanteras strngar i ekvationer.

* connect

Exakt hur fungerar connect()?

Beskrivningen av connect-semantiken (B.2) mste vara fel.

Status: Being rewritten.

* Kvalificerade identifierare

What can `foo' be in "foo.bar"? Different things if looking for a
class definition or a variable?

** A variable (or constant) in scope

    module Resistor
      Pin p,n;
      parameter Real r;
    equation
      p.i = n.i;
      (p.v - n.v) = p.i * r;
    end Resistor;

** A class in scope

The class will often (always?) be a package.

    package Foo
      constant Real x = 17.0;
    end Foo;

    model Bar
      Real y = Foo.x;
    end Bar;

But e.g. in modifications it may be common with other classes

    model Foo

      type Bar
        constant Real x = 17.0;
      end Bar;

      Bar b;
    end Foo;

    model Baz
      extends Foo(Bar.x = 4711.0);
    end Baz;

** A package in a file "foo.mdc"

    module Foo
      Modelica.SIunit.Area a;
    end Foo;

* How does = work in declarations

Is

    model M
      Foo x = y;
    end M;

the same as

    model M
      Foo x;
    equation
      x = y;
    end M;

This is almost true, but not completely.

* Allt r ekvationer

Tydligen s ska tilldelningar vid variabeldeklarationer betraktas som
ekvationer. S

	model Foo
	  Real x = 17.0;
	end Foo;

r ekvavilent med

	model Foo
	  Real x;
	equation
	  x = 17.0;
	end Foo;

** Equations in restricted classes

Records, and other restricted class types can't contain equations. But
assigment modifiers are equations, which contradicts this.

	record Foo
	  Real X = 17;
	end Foo;

should be equal to

	record Foo
	  Real x;
	equation
	  x = 17;
	end Foo;

except that that form is not valid. This probably means that the class
restriction inference has to differentiate between explicit and
implicit equations.

** Ersttning av ekvationer

Hilding tyckte visst att "x = 17" skulle ersttas av "x = 15" i N.

    model M
      Real x;
    equation
      x = 17;
    end M;

    model N
      M a(x=15);
    end N;

More precise rules?

* Conflicting modifications

If the grammar change of the "modification" production rule is made,
what are the semantic consequences?

Consider the following program:

	class Foo
	  parameter Real x = 17;
	end;

	class Bar
	  Foo a(x = 4711);
	  Foo b(x = 1) = a;
	end;

Does this even make sense when the class is not Real, Integer, String
or Boolean? The normal semantics for equality modifications is to
rewrite it as a separate equation, so it might not be a problem, other
than an implementation hassle.

	class Foo
	  parameter Real x = 17;
	end;

	class Bar
	  Foo a(x = 4711);
	  Foo b(x = 1);
	equation
	  b = a;
	end;

On reading this again I can't remember what the problem was...

* What can you modify?

Both variables and class declarations?

* connect and array subscripts

If you write

	connect(a[<expression>],x)

does <expression> have to be a constant (integer) expression?
Otherwise it seems a little hard to generate connection sets.

* Inconsistencies

	constant input Real foo

* Predefined types

Can the types of the predefined types Real etc. really be described in
Modelica without breaking the restrictions of the 'type' class form?
Not to mention the 'value' mess.

* Protected elements

Should inherited protected elements be accessible to the new class?

	class A
	protected
	  Real x;
	end A;

	class B
	  extends A;
	  Real y = x + 1;
	end B;

* Types of expressions

Nothing is said in the report about types of expressions. On reading
the design minutes I at least found out that `/' on two integer should
convert them to reals and do a real division.

More could be said about types. The grammar doesn't even differentiate
between real and integer literals.

** Integer division

The division operator `/' always produces a Real result.

The operators div() and rem() are defined.

The operator div() is defined in the report as returning a Real, which
can't possible be sensible.

* Arrays

Arrays are indexed from 1 and up. This is not mentioned in the
report. There is hardly any mention of how many dimensions a matrix
can have. And what the start-step-stop syntax means. For us who do not
know Matlab by heart, this need a explanation in the report.

Accessing componentes of an array of complex objects seems to be
possible.

	Record R
	  Real x;
	  ...
	end R

	...
	  R r1[17];
	  R r2[17]
	equation
	  r2.x = r2.x;
	...

This is not explained either, as far as I can tell.

* Type equality(?) in equations

What are the requirements on two components that are "=" in an
equation?

	class A
	   ...
	end A;

	class B
	  ...
	end B;

	class C
	  A a;
	  B b1;
	  B b2 = a
	equation
	  a = b1;
	end C;

According to an example in the report ther might be enough with a
subtype relation.

* Recursive equations

From the report:

      transpose(a) * [1; x; x^2; ... x^n]

if we could form the vector of increasing powers of x. A recursive formulation is possible. 

      xpowers[1] = 1;
      xpowers[2:n+1] = xpowers[1:n]*x;
      y = transpose(a) * xpowers;

The recursive formulation would be expanded to 

      xpowers[1] = 1;
      xpowers[2] = xpowers[1]*x;
      xpowers[3] = xpowers[2]*x;
      ...
      xpowers[n+1] = xpowers[n]*x;
      y = transpose(a) * xpowers;

Thinking about this I see that there is no problem at all. The array
equation is unrolled in the normal fashion.

* while

How are while loops treated in equation sections?

* enable

What are the semantics of the enable attribute?

* Restrictions on the top-level model

Does the last class in the file have to be a `model' (or a compatible
`class')?
