Function signatures for type safe function partial application

[Rüdiger Franke]

OpenModelica boxes arguments of functions that are passed as input to other functions. The actual types of the arguments appear to be only known during the boxing/unboxing operations. This hinders the generation of type safe code. The actual function signatures should be accessible from PARTEVALFUNCTION and FUNCTION_PTR (see SimCodeTV.mo).

See the following example:

partial function part
  input Real u;
  output Real y;
end part;

function func
  input Real u;
  input Real v;
  output Real y;
algorithm
  y := u + v;
end func;

function feval
  input part f;
  input Real u;
  output Real y;
algorithm
  y := f(u);
end feval;

model m
  input Real u = 0; // prevent presolving
  Real y = feval(function func(v = 2), u + 1);
end m;

When generating code for function feval, the signature of the input part should be accessible from the FUNCTION_PTR argument.

When generating code for model m, the signatures of the used function func and of the expected part should be accessible from PARTEVALFUNC.

So far only the types of the additional arguments of func (v in the example) can be derived from the expList contained in PARTEVALFUNC.

[Martin Sjölund]

It does not need to be there because the C runtime only passes void pointers. What code do you want to expand this to in C++?

[Rüdiger Franke]

In the model m I want to create a kind of a closure that holds the additional argument v and provides an operator() that calls func:

    class _Closure_func
    {
      double &v;
     public:
      _Closure_func(double &v)
        : v(v)
      {}
      double operator()(double u) {
        return func(u, v);
      }
    };

This way the code for the function call in model m can look like:

  y = feval(_Closure_func(2.0), 1.0 + u);

The code for the function feval can look like

template <class _fnptr_part>
double feval(_fnptr_part f, double u)
{
  double y;
  y = f(u);
  return y;
}

The problem is the missing type information for for u and v (at least for u) in PARTEVALFUNC when generating code the closure. The function itself can be implemented with template, because Modelica does not enforce inheritance of func from part. But a specific name containing the interface function part should be used -- this is not known in the current FUNTION_PTR.