WG 2.11 Research at the University of Passau (Draft)
===================================================

The main objective of our research is to increase the execution
efficiency of programs.

Whenever demands other than execution speed are made of
of domain-specific programming languages, the implicitly
assumption seems to be that they not ruin performance.
Without regard of performance, domain-specific applications
could be developed quite simply, based on interpreters
written in a general-purpose programming language.

Efficiency implies a short turn-around times for interactive
applications and, in the world of high-performance computing,
competition with hand-written code at the level of assignments
to memory cells.

It seems useful to distinguish between choices made by
the limitations of science and technology and those justified
by the state of the art in software engineering and in the
education of programmers. Therefore, our research plan is
divided into two tiers.

The first tier concentrates on theoretical background
and technical feasibility. Under the premise that, due to
its flexibility, an interpreter should be the starting point
for the implementation of a domain-specific language,
we plan to investigate the impact of partial evaluation on
performance by elimination of the interpretative overhead.
Of special concern is the point in time when the partial
evaluation happens:

(1) at program construction time, when analysis time is cheap,
(2) at program load time, when still no real-time behaviour is
    expected and some structural parameters can be determined, or
(3) at run time, when all information is available but the execution
    time saved must outweigh the time spent in the program analysis.

One choice of language we consider is OCaml, where we can make
experiments with bytecode and native code.

The second tier builds on the techniques developed in the first tier,
which prove to be efficient and feasible. In their raw form, they
will most likely not be usable in a standard software engineering
process, given the level of education of present-day programmers.
Rather they will have to be adapted for existing practice. Different
application communities use different techniques to achieve similar
goals, but it is not well understood how these techniques can be
unified or ported to another community.

One attempt of creating an interface is the notion of a skeleton.
A skeleton is a program schema for which an efficient implementation
exists and which can be customized by problem-specific program pieces.
In functional programming, a skeleton can be expressed as a higher-order
function whose arguments are the customizing functions. In object-oriented
programming, a skeleton can be expressed as a class whose customizing
functions are defined by the implementation of distinguished methods.

In practice, the use of skeletons might appear as too restrictive for
many programmers. The less stringent concept of a design pattern
prescribes neither types nor dedicated functions. A challenge for
domain-specific program generation is to improve the quality of the
programmer's work by adding formal strength, like present in a skeleton,
without strangling productivity. The need for formal strength comes from
practical requirements like safety, reliability, reuse of components and
control over various costs of software.