WO2014161731A1 - Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse - Google Patents

Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse Download PDF

Info

Publication number
WO2014161731A1
WO2014161731A1 PCT/EP2014/055751 EP2014055751W WO2014161731A1 WO 2014161731 A1 WO2014161731 A1 WO 2014161731A1 EP 2014055751 W EP2014055751 W EP 2014055751W WO 2014161731 A1 WO2014161731 A1 WO 2014161731A1
Authority
WO
WIPO (PCT)
Prior art keywords
type
function
program
expression
binding time
Prior art date
Application number
PCT/EP2014/055751
Other languages
English (en)
French (fr)
Inventor
Kai Trojahner
Original Assignee
Realtime Technology Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Realtime Technology Ag filed Critical Realtime Technology Ag
Priority to US14/782,169 priority Critical patent/US10048951B2/en
Priority to EP14711534.9A priority patent/EP2965199A1/de
Publication of WO2014161731A1 publication Critical patent/WO2014161731A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/436—Semantic checking
    • G06F8/437—Type checking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/49—Partial evaluation

Definitions

  • the invention relates to a method for checking and / or transforming a computer program that is present in a programming language that supports first-class functions.
  • Computer programs are used to control the hardware in computer or computer systems and to solve problems with the computer systems.
  • Computer programs are typically provided by a programmer at a higher level, e.g. in a high-level programming language, and then translated into a machine code that is directly interpretable or executable by the hardware.
  • Claim 1 describes a method for checking and / or transforming a computer program that is in a programming language that supports first-class functions. It will be one
  • a function type is only accepted together with the static binding time.
  • the result of the case distinction is not known statically, but only at runtime, for example if the expression representing the condition has a dynamic binding time and it is thus not statically known whether the condition is met or not the condition representing expression is true or false. If expressions with a function type are given as possible results of such a dynamic case distinction, eg in the branches of an if-else expression, a function would result from the case distinction which is not statically known and thus not by partial evaluation of the program can be eliminated before the term. This is indicated by the error message.
  • rules according to the above notation are to be understood in such a way that the one or more prerequisites formulated above the horizontal hyphen are checked in the application of the respective rule and the one or more conclusions drawn below the hyphen are derived if the prerequisites are fulfilled.
  • a general overview of preferred typing rules is contained in the following tables 3a, 3b, 3c and 3d, which are explained in connection with preferred exemplary embodiments.
  • a first function type Tn-> Ti2 is assumed to be subtype of a second function type T21-> T22 if and only if each definition type T21 of the second function type is a subtype of the respective corresponding definition type Ti 1 of the first function type and Target type T12 of the first function category is a subtype of the target type T22 of the second function category.
  • the assumption that the definition type T21 of the second function type is a subtype of the definition type Tu of the first function type means that the first function type must describe a function that can at least accept and process those arguments or operands that the second function type accepts and processes
  • the prerequisite that the target type T12 of the first function type is a subtype of the target type T22 of the second function type means that the first function type must describe a function that provides a printout with a type T12 that may be used admissibly everywhere, where an expression of type T22 is expected.
  • a first pair type T11 XT12 is assumed as a subtype of a second pair type T21 XT22 if the type Ti1 of the first element of the first pair type is a subtype of the type T21 of the first element of the second pair type and the type T12 of the second pair type Element of the first pair type is a subtype of the type T22 of the second element of the second pair type.
  • This makes it possible to use a pair type where a pair type is expected whose elements are supertypes of the types of elements of the existing pair type.
  • the above provision is preferably by a Subtype rule implemented, which is used to check if a pair type is a subtype of another pair type.
  • a rule SUBPAIR is given below by way of example.
  • the above rule is preferably implemented by a subtype assignment rule, which is preferably checked when an expression has been assigned to a type that does not satisfy a condition of a rule to be checked for the typification of a superordinate expression in order to assign a supertype to the expression if possible. which fulfills the requirement. If this is not possible, a type error is preferably output and an error message is generated. Otherwise, the appropriate type is assigned, the type mapping rule to apply to the parent expression, and the type checking continues.
  • a subtype assignment rule T-SUB as described above is exemplified below: : Hey: T
  • the definition of the subtypes thus leads to the fact that in type checking an expression can always satisfy a requirement imposed on its type by a type assignment rule even if the type assigned to it is a subtype of the type required by the type assignment rule and the required type is well-formed is. If it is described in the present description as a prerequisite for the successful application of a type assignment rule that one or more expressions are assigned a specific type, it is to be understood that the respective rule may instead require that a type be assigned to the respective expressions which is identical to the particular type or is a well-formed subtype of the particular type.
  • the type system is preferably defined by a set of rules which are applied to assign a type to each expression of the program.
  • each type of expression ie in particular function definitions, pair definitions, function applications, conditional expressions, etc.
  • a type assignment rule by which the expression is checked, ie its prerequisites are checked and by means of which a type is assigned to the expression if the prerequisites usually fulfilled.
  • the subtype mapping rule described above represents an additional rule that is preferably applied to a subexpression of a parent expression that is being checked against a type mapping rule to be checked, if the subexpression specifies a parent expression specified in the type mapping rule for the parent expression.
  • a conditional expression whose condition is indicated by a first subexpression e p and whose at least two cases are indicated by a second and a third subexpression e, e ', if the first subexpression e p is a first type Mbool with a boolean base type bool and an arbitrary first binding time M is assigned and when the second and third subexpression e, e 'are each assigned an identical second type MC with any identical basic type C and the first binding time M, the second type MC, ie the common type of the second and third subexpression e, e ', associated.
  • the above rule is preferably implemented by a type-assignment rule which is checked when a conditional expression is to be typed.
  • a rule T-COND is exemplified below. rhe ": bool T he: MC ⁇ he ': MC
  • an expression defining an application of a function can not be accepted if a definition type of the has a static binding time, and a dynamic binding time is assigned to the corresponding operand to which the function is applied.
  • the above rule is implemented by a type assignment rule which is checked when an expression defining a function application is to be typed.
  • T-APP is exemplified below:
  • Another object of the invention is a method for transforming a computer program that is in a programming language that supports first-class functions in which a type check of the program or at least part of the program is performed to give each expression of the program or part of the program a type which consists of a basic type and a binding time, wherein the set of basic types comprises at least base types for describing simple values and a function type for describing functions, and the amount of binding times comprises at least one static binding time and one dynamic binding time, wherein the Type checking a function type is only accepted together with the static binding time. If the program or part of the program is accepted by type checking, partial evaluation of the program or part of the program eliminates all first-class functions contained in the program or part of the program.
  • the method for transforming a computer program comprises a type checking of the program as described above.
  • the advantageous embodiments and advantages described above in relation to the method for checking and / or transforming a computer program apply correspondingly to the method for transforming the computer program.
  • the method includes, if the type checking is successful, the program is partially evaluated to convert the program into an equivalent program without first-class functions.
  • the partially evaluated program thus fulfills the functionality of the original program and, at the same time, can be executed with less runtime since the additional operations associated with the use of first-class functions, such as function pointer dereferencing and dynamic memory management, are unnecessary. Accordingly, the program may even be executed on hardware that does not support the above functions.
  • programs can be developed using first-class functions, thereby increasing the efficiency of development, for example, through reuse of functions and modular program design without sacrificing performance on the hardware in the eventual implementation of the resulting program Class occur.
  • the described verification method can be reliably determined in a small amount of time, whether a given program is transformable in the manner described, otherwise a precise statement about the cause of the error in the program made and displayed to the user, so that the error can be easily eliminated can and the programming permissible, ie transformable, programs with little effort is possible.
  • the partially evaluated program or the program with the partially evaluated expression is preferably translated into a machine code which can be directly executed by a target computer system, preferably at instruction set level.
  • the partially evaluated program can be compiled by a compiler and then optionally assembled by an assembler. Subsequently, the assembled program can be directly executed by a target computer system.
  • the target computer system may be another computer system In principle, however, the same computer system can also be used as the one on which the checking and / or the partial evaluation and / or compilation and / or assembly is carried out.
  • the program with the partially evaluated expression or the partially evaluated program is translated into a machine code for a hardware platform that does not support function pointers and / or that does not support dynamic memory management.
  • the result is thus a complete evaluation of the original computer program according to the programming language of the original program underlying evaluation semantics, first a static, that takes place at the time of translation, partial evaluation and then the remaining dynamic, ie taking place at runtime or execution time, evaluation of partially evaluated program, wherein the remaining evaluation is preferably carried out by direct execution of a machine code generated from the partially evaluated program.
  • the method (s) according to the invention can in each case be carried out in principle on one or more computer systems, for example designed as personal computers.
  • the rules for the order of the binding times according to Table 3a as well as the rules for checking the well-formedness of types according to Table 3b and the rules for checking the existence of a subtype relationship with the exception of the rule SUB-BASE are in the above general description explained.
  • the SUB-Base rule describes that a base type always has only itself as a super or subtype, so that basic types are not interchangeable in the present embodiment.
  • the rule T-VAR assigns the occurrence of a variable x in an expression to the type T if the respective context ⁇ contains a corresponding type assignment or type annotation x: T.
  • the rule T-VAR thus serves to look in the context ⁇ whether the type T is annotated for the variable x in the context und and in this case assign the variable x to this type T.
  • the T-VAR rule is used when a variable occurs in a parent expression and its type is significant for the application of a typing rule to be used for the parent expression type.
  • the rules T-PRJ 1 and T-PRJ2 are to be used for typing expressions representing a projection of a pair, i. expressions of the kind fste, snd e, where the term fste means the projection onto the first element ei of a pair (ei, e2) and the expression snd e means the projection onto the second element e2 of a pair (ei, e2) (See the evaluation rules E-FSTARG, E-FST, E-SNDARG, E-SND in Table 2).
  • the type mapping rules T-PRJ 1 and T-PRJ2 determine that such an expression is assigned the type corresponding to the respective, i.e. is assigned to the first and second, element of the pair.
  • the rule T-CONST is applied to constant symbols c and assigns to a constant symbol c a type T, which in the assignment state belle type (c) (see Table 4 below) is given as a possible type of this symbol.
  • the static symbols S are assigned to the constant symbols.
  • type (c) two different types of functions are provided in type (c), namely, a function type that describes a function that maps from a static type to a static type, and a function type that has a function which maps from a dynamic type to a dynamic type. This takes into account the fact that the primitive functions can be applied both to static arguments, in which case they provide static values, and to dynamic values, in which case they deliver dynamic values.
  • the respective operator constant is assigned the type which is expected by the typing rule to be applied to the superordinate expression containing the operator in order to check whether the typing rule can be successfully applied.
  • Table 5 below shows the evaluation rules according to which the partial evaluation takes place.
  • the symbol I e l means that the expression e is partially evaluated, and the right side of the equations each indicates the result of the partial evaluation.
  • the curly braces on the right side of the equations each serve to distinguish the case.
  • the semantics underlying the partial evaluation corresponds to the semantics of the programming language given in Table 2.
  • the first example concerns the functions add, sub and apply defined in the program code 1 given at the outset.
  • Rule Application Diagram 1 shows which typing rules are applied to which expressions to typify these functions.
  • Xb D int. + ( ⁇ , b)
  • the dynamic binding time is assumed, because for the basic type int the dynamic binding time is generally permissible.
  • the binding time S is assumed since only the static binding time is allowed for function types.
  • the user could also be asked in the context of the method to perform an explicit binding time annotation for the variables a, b and / or f.
  • the target type of the add, sub and apply functions also annotated in the C syntax in program code 1 is irrelevant in the present exemplary embodiment and is ignored.
  • the functions add and sub can be typed successfully.
  • the typification of the function sub is not shown in the diagram because it corresponds to the typing of the equivalent function add.
  • the functions add and sub are assigned the type S (Dint-> S (Dint-> Dint)), i. it is determined that the add and sub functions are to be used statically, respectively, and it is recognized that the add and sub functions each map a dynamic value of basic type int (definition type) to a static function (destination type) which is a dynamic one Value from basic type int to a dynamic value of basic type int.
  • the function type as the target type results from the consideration of the functions add and sub as two nested unary functions instead of a two-digit function.
  • the apply function is also successfully typed, ie it is recognized that the apply function, as described above, can be transformed by partial evaluation into a first-order function.
  • the key here is that the variable f in the body of the apply function is not used as part of an expression that requires a dynamic type for f. Instead, the definition of the apply function requires the transfer of a static function variable, so as to ensure that the value of the function f is statically known at the location of the function application (fa) b ( ⁇ notation). It should be taken into account that in the program code 1, not the function apply, but the function foo represents the entry-level function. Otherwise, the apply function might have to fulfill the additional condition that it must not have any static function variables, so that annotating the variable f as a static function would result in a type error and hence an error message for the user.
  • Example 2 Example 2:
  • the following program code 5 represents another program, which is checked with the method.
  • the program according to program code 5 and 6 can be transformed by partial evaluation into a program without functions of first class.
  • the conditional expression if true then add true sub in program code 6 can be statically evaluated to add, so that the variable f is statically known at the point of its call within the scope of the apply function. Thus the type check is successful and the program is allowed.
  • This simplified program can then be translated into machine code for any hardware and executed by the particular low-end hardware, whether the hardware supports function pointers or dynamic memory management.
  • Example 3 The following example illustrates a type error that occurs when a program having a first class function is not transformable by partial evaluation into a first order equivalent program.
  • a static bonding time S (D int> ⁇ D int) j means that the expression e t comprising:
  • T-LAM known that he ⁇ t.
  • e e In order to check whether the T-COND rule can still be successfully applied, it is checked whether one or more of the expressions p, et or e e can be subtype-assigned to a supertype that allows the rule to be used. Since the Dbool type does not have a supertype except itself, it depends on whether one of the expressions et or e e can be assigned a suitable supertype. For this purpose a hypothetical supertype DC with a dynamic binding time is assumed, which is used in the rule T-SUB, so that the following results for this:

Abstract

Die Erfindung betrifft ein Verfahren zur Überprüfung und/ oder Transformation eines Computerprogramms, das in einer Programmiersprache vorliegt, welche Funktionen erster Klasse unterstützt, bei dem eine Typüberprüfung des Programms oder zumindest eines Teils des Programms durchgeführt wird, um jedem Ausdruck des Programms oder Teils des Programms einen Typen zuzuordnen, der aus einem Grundtypen und einer Bindungszeit besteht, wobei die Menge der Grundtypen mindestens Basistypen zur Beschreibung einfacher Werte und einen Funktionstypen zur Beschreibung von Funktionen umfasst und die Menge der Bindungszeiten mindestens eine statische Bindungszeit und eine dynamische Bindungszeit umfasst und wobei bei der Typüberprüfung ein Funktionstyp nur gemeinsam mit der statischen Bindungszeit akzeptiert wird.

Description

Verfahren zur Überprüfung und/oder Transformation eines Computerprogramms mit statischen Funktionen erster Klasse
Die Erfindung betrifft ein Verfahren zur Überprüfung und/ oder Transformation eines Computerprogramms, das in einer Programmiersprache vorliegt, welche Funktionen erster Klasse unterstützt. Computerprogramme dienen der Ansteuerung der Hardware in Computeroder Rechnersystemen und zur Lösung von Problemen mit den Computersystemen. Computerprogramme werden von einem Programmierer typischerweise auf einer höheren Ebene, z.B. in einer höheren Programmiersprache, entworfen und anschließend in einen Maschinencode übersetzt, welcher durch die Hardware direkt interpretierbar oder ausführbar ist.
Ein wichtiges Anwendungsgebiet von Computersystemen ist das Gebiet der Computergrafik, d.h. des Erzeugens bzw. "Renderns" von Daten zur Darstellung insbesondere dreidimensionaler Grafiken unter Verwendung von Computersystemen bzw. von speziell für diese Anwendungen ange- passten Grafikprozessoren.
Bei dem Entwurf von Programmen für diese Anwendungen muss stets ein Kompromiss zwischen der Bildqualität der Grafiken und der Renderge- schwindigkeit eingegangen werden, wobei die entsprechenden Prioritäten stark mit dem jeweiligen Anwendungsbereich variieren. Während z.B. bei der Erzeugung von Offline-Inhalten Renderzeiten von mehreren Stunden zur Erzeugung einer größtmöglichen Realitätsnähe der Grafiken akzepta- bei sind, erfordert eine Echtzeit- Visualisierung, dass mehrere Bilder pro Sekunde mit der besten in dem verfügbaren Zeitrahmen erreichbaren Qualität erzeugt werden. Diese konkurrierenden Zielsetzungen haben zu der Entwicklung einer Vielzahl von verschiedenen Renderalgorithmen geführt, die alle einen individuellen Kompromiss zwischen der Visualisierungsqualität und der Rendergeschwindigkeit realisieren. Zudem haben die vorstehenden Zielsetzungen zu der Entwicklung einer Vielzahl von parallelen Hardware-Modellen und Programmiermodellen geführt, die auf schnelles 3D-Rendern ausgerichtet sind.
Eine besondere Bedeutung für die realitätsnahe Visualisierung bei Com- putergrafiksoftware kommt Shader- Programmen zu, welche für die Darstellung von Schattierungen auf den Oberflächen darzustellender, insbesondere dreidimensionaler geometrischer Objekte zuständig sind, wobei die Darstellung von einem jeweils angenommenen Lichteinfall und Ober- flächenmaterial abhängt. Diese Shaderprogramme können eine hohe Komplexität aufweisen und werden im Rahmen eines Rendervorgangs viele Male ausgeführt und sind somit für die erreichbaren Renderzeiten der Grafiksoftware typischerweise ausschlaggebend. Die Entwicklung neuer Shaderprogramme bzw. "Shader" von Grund auf für jede mögliche Kombination und Ausgestaltung von Renderprozeduren und Hardwareplattformen ist mit einem hohen wirtschaftlichen Aufwand verbunden. Deshalb ist es wünschenswert, Shaderprogramme in einer Shaderpro- grammiersprache zu entwerfen, die im Gegensatz zu hardwareplattform- spezifischen Programmiersprachen nicht an eine ganz bestimmte Hardware gebunden ist. Durch Modularisieren der Shaderprogramme in Codefragmente, die für eine bestimmte Hardwareplattform oder eine bestimmte Renderprozedur spezifisch sind, einerseits und Codefragmente, die davon unabhängig sind, andererseits könnten große Mengen von Computerpro- grammcode für verschiedene Renderer- Implementierungen wiederverwen- det werden, wodurch der Aufwand für die Entwicklung von Shader- bzw. Renderprogrammen reduziert und die Produktivität der Softwareentwicklung gesteigert würde. Ein besonders effektiver und gleichzeitig einfacher Mechanismus zur Modularisierung von Programmen sind Funktionen höherer Ordnung. Eine Funktion wird Funktion höherer Ordnung oder "Funktional" genannt, wenn sie eine oder mehrere Funktionen als Argument annimmt oder eine oder mehrere Funktionen als Rückgabewert liefert. Andere Funktionen werden Funktionen erster Ordnung genannt. Eine Programmiersprache, die Funktionen höherer Ordnung unterstützt, muss so genannte Funktionen erster Klasse unterstützen, d.h. dass die Sprache Funktionen ebenso behandelt wie andere Werte. Eine Funktion erster Klasse, welche auch als first-class Funktion bezeichnet wird, kann z.B. einer Funktion höherer Ordnung als Argument übergeben werden, von einer Funktion höherer Ordnung als Rückgabewert geliefert werden, einer Variablen als Wert zugeordnet werden oder als Element in einer Datenstruktur verwendet werden. Trotz des Potentials von Funktionen erster Klasse zur Vereinfachung des Programmentwurfs unterstützen bisherige Shadersprachen Funktionen erster Klasse nicht, weil deren Implementierung im Allgemeinen die Unterstützung von Funktionszeigern und ein dynamisches Speichermanagement erfordert, um die Umgebung bzw. "Closure" einer Funktion mit den von der Funktion referenzierten nicht-lokalen Werten allozieren zu können. Diese Implementierungstechniken führen zu zusätzlichen Instruktionen und folglich zu einer Verlängerung der Laufzeit, die die erreichbare Renderleistung erheblich beeinträchtigen kann, da Shaderpro- gramme typischerweise Millionen Male pro Sekunde ausgeführt werden. Der größte Teil der Laufzeitverlängerung ist durch das dynamische Spei- chermanagement bedingt, aber auch die Dereferenzierung von Funktionszeigern kann zu einem vergeblichen Zugriff auf den Befehlspufferspeicher ("cache miss") und somit zu einem spürbaren Zeitverlust führen. Ferner unterstützen viele Renderplattformen wie z.B. CUDA 1.x, OpenCL oder GLSL weder Funktionszeiger noch dynamisches Speichermanagement.
Aufgabe der Erfindung ist es, ein Verfahren anzugeben, das es ermöglicht, Computerprogramme mit Funktionen erster Klasse daraufhin zu überprüfen, ob sich das jeweilige Programm in ein in Bezug auf seine Funktionali - tät identisches, äquivalentes Programm transformieren lässt, das keine Funktionen höherer Ordnung bzw. erster Klasse aufweist und somit mit einer hohen Renderleistung insbesondere auch auf einer Hardware ausgeführt werden kann, welche keine Unterstützung für Funktionszeiger und/oder dynamische Speicherverwaltung bietet. Die Überprüfung soll mit geringem Zeitaufwand durchführbar sein und ggf. eine genaue Angabe des Programmbestandteils ermöglichen, aufgrund dessen das Programm nicht transformierbar ist. Ein transformierbares Programm soll entsprechend transformiert werden und dann, ggf. nach Übersetzung in einen entsprechenden Maschinencode, auf der jeweiligen Hardware ausgeführt werden.
Die Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Anspruch 1 beschreibt ein Verfahren zur Überprüfung und/oder Transformation eines Computerprogramms, das in einer Programmiersprache vorliegt, welche Funktionen erster Klasse unterstützt. Es wird eine
Typüberprüfung des Programms oder zumindest eines Teils des Programms durchgeführt, um jedem Ausdruck des Programms oder Teils des Programms einen Typen zuzuordnen, der aus einem Grundtypen und einer Bindungszeit besteht, wobei die Menge der Grundtypen mindestens Basistypen zur Beschreibung einfacher Werte und einen Funktionstypen zur Beschreibung von Funktionen umfasst und die Menge der Bindungszeiten mindestens eine statische und eine dynamische Bindungszeit um- fasst. Erfindungsgemäß wird bei der Typüberprüfung ein Funktionstyp nur gemeinsam mit der statischen Bindungszeit akzeptiert.
Im Rahmen der Erfindung wurde erkannt, dass ein Computerprogramm, das in einer Programmiersprache vorliegt, die Funktionen erster Klasse unterstützt, durch partielle Auswertung in ein Programm ohne Funktionen erster Klasse transformiert werden kann, wenn alle Ausdrücke, denen ein Funktionstyp zugeordnet wird, eine statische Bindungszeit aufweisen, d.h. dass der jeweilige Ausdruck bereits vor der Ausführung des Programms, z.B. zum Zeitpunkt des Kompilierens, auswertbar ist. Anderer- seits kann ein Ausdruck, der eine dynamische Bindungszeit aufweist, nicht als statisch bekannt angenommen werden, sondern ist erst zur Laufzeit des Programms auswertbar und kann somit nicht vor der Ausführung durch partielle Auswertung eliminiert werden. Dies ist nachfolgend anhand zweier unterschiedlicher beispielhafter Programmcodes er- läutert, die in einem hypothetischen Dialekt der Programmiersprache C notiert sind.
Programmcode 1:
int apply( ((int , int) => int) f , int a, int b) {
return f ( a , ) ;
}
int add ( int a, int b) { return a + b ; }
int sub ( int a, int b) { return a - b; }
int f oo ( bool p, int a, int b) _
int r ;
if (p) ΐ
r = apply ( add, a, b) ;
} eise {
r = apply ( sub, a, b) ;
}
return r ;
In Programmcode 1 ist die Funktion apply eine Funktion höherer Ord- nung. Die Funktion apply nimmt eine Funktion f als Argument entgegen, die zwei Integerwerte auf einen weiteren Integer abbildet, wie in dem Pro- grammcode durch den annotierten Funktionstypen "(int, int)— >int" angegeben ist. Die Funktion apply wendet f auf die zwei weiteren Integer- Argumente a, b an und gibt das Ergebnis zurück. Die Funktion foo ver- wendet die Funktion apply, um zwei Integerwerte abhängig von dem Wert des Bool'schen Arguments p entweder zu addieren oder zu subtrahieren.
Das Programm höherer Ordnung gemäß Programmcode 1 kann durch partielle Auswertung zur Kompilierzeit in ein äquivalentes Programm ers- ter Ordnung, d.h. ohne Funktionen erster Klasse, transformiert werden. Ein solches transformiertes Programm ist nachfolgend als Programmcode 2 angegeben. In dem Programmcode 2 sind die Aufrufe der Funktion apply jeweils durch den Rumpf der Funktion apply ersetzt, so dass die Funktionen add und sub, die erster Ordnung sind, direkt aufgerufen werden. Das Ersetzen der Funktionsaufrufe wird auch als Inlining bzw. Expandieren bezeichnet. Programmcode 2: int add ( int a, int b) { return a + b; }
int su ( int a, int b) { return a - b ; }
int foo ( bool p, int a, int b) {
int r ;
if (p) {
r = add ( a, b) ; // apply ( add, a, b)
} eise {
r = sub ( a, b) ; // appl ( sub, a, b)
>
return r ;
Prinzipiell lassen sich aber nicht alle Computerprogramme mit Funktionen erster Klasse durch eine wie vorstehend beschriebene Expansion in ein äquivalentes Programm erster Ordnung transformieren, wie durch den nachfolgenden Programmcode 3 gezeigt ist, welcher eine alternative Definition der Funktion foo darstellt:
Programmcode 3: int foo ( bool p, int a
( ( int , int ) => int ) f
if (p) {
f = add;
} eise {
f = sub ;
>
return apply (f , a , b) ;
Der Programmcode 3 deklariert einen Bezeichner bzw. eine Variable f , welche eine Funktion repräsentiert, und zwar entweder die Funktion add oder die Funktion sub, abhängig von dem Wert des Bool'schen Arguments p der Funktion foo. Zwar kann die Definition der Funktion apply von dem Compiler formal durch Inlining eingesetzt werden, so dass der Aufruf der Funktion apply in dem Programmcode 3 die Form f(a, b) annimmt. Da der Wert von f aber von dem Wert der Variablen p abhängt, kann weder add noch sub direkt angewendet werden, wenn der Wert von p nicht statisch bekannt ist, was zum Beispiel dann der Fall ist, wenn es sich bei der Funktion foo um eine so genannte Einstiegsfunktion eines Programms handelt, bei der die Programmausführung beginnt.
Die vorstehenden Programmcodes 1 bis 3 veranschaulichen, dass sich bestimmte Programme mit Funktionen erster Klasse durch partielle Auswertung in äquivalente Programme erster Ordnung, d.h. Programme ohne Funktionen erster Klasse, transformieren lassen und andere Programme nicht. Nur wenn Funktionen in dem Programm statisch bekannt sind, kann das Programm durch partielle Auswertung in ein Programm erster Ordnung transformiert werden. Indem das Verfahren gemäß der vorliegenden Erfindung eine Typüberprüfung durchführt, die den Ausdrücken des Programms sowohl einen Grundtypen als auch eine Bindungszeit zuordnet, und bei der Typüberprüfung ein Funktionstyp nur gemeinsam mit der statischen Bindungszeit akzeptiert wird, stellt das Verfahren folglich fest, ob sich das Programm durch partielle Auswertung in ein Programm erster Ordnung, d.h. ohne Funktionen erster Klasse, transformie- ren lässt. Für den Programmcode 1 ist dies konkret in dem "Beispiel 1" veranschaulicht, welches auf die nachstehende allgemeine Beschreibung folgt und welches ein an diesem konkreten Programm durchgeführtes Überprüfungsverfahren im Detail beschreibt. Da die erfindungsgemäße Überprüfung und Klassifizierung auf einer Typüberprüfung beruht, kann diese ohne Auswertung des Programms erfolgen. Typüberprüfungen sind an und für sich bekannt und beruhen auf einem für die jeweilige Sprache spezifischen Satz von Typisierungsre- geln, welche zusammen ein Typsystem definieren und welche die Ausdrü- cke eines Programms nach der Art der Werte klassifizieren, die sie berech- nen. Die Typisierbarkeit aller Ausdrücke eines Programms oder Programmteils durch erfolgreiche Anwendung der Typisierungsregeln bestimmt, ob das Programm bzw. der Programmteil zulässig ist oder nicht. Die Erfindung erweitert die bekannte Typ Überprüfung dahingehend, dass jedem Ausdruck sowohl ein Grundtyp, der den Wert des Ausdrucks beschreibt, als auch eine Bindungszeit, die den Zeitpunkt der Auswertung des Ausdrucks beschreibt, zugeordnet werden. Das Typsystem ist speziell für eine zweistufige Auswertung des Programms ausgelegt, welche eine statische, d.h. zur Übersetzungszeit erfolgende, partielle Auswertung des Programms und eine darauf folgende dynamische, d.h. zur Laufzeit erfolgende, restliche Auswertung des Programms umfasst. Das Typsystem differenziert dabei nach Ausdrücken mit statischer Bindungszeit, d.h. Ausdrücken, die zur Übersetzungszeit partiell ausgewertet werden kön- nen, einerseits und Ausdrücken mit dynamischer Bindungszeit, d.h. Ausdrücken, die nur zur Laufzeit ausgewertet werden können, andererseits und erlaubt dabei selektiv die Formulierung von Programmen, die durch die statische partielle Auswertung in Programme ohne Funktionen erster Klasse umgewandelt werden können.
Durch die kombinierte Typisierung nach Grundtypen und Bindungszeiten ist in besonders einfacher Weise und ohne vorherige Auswertung des gesamten Computerprogramms feststellbar, ob das Programm in ein äquivalentes Programm erster Ordnung transformierbar ist oder nicht. Es kann dabei mit geringem Aufwand sichergestellt werden, dass zumindest alle diejenigen Programme zurückgewiesen werden, die Funktionen erster Klasse enthalten und bei denen die beschriebene Transformation nicht möglich ist. Bei der Typüberprüfung wird jeder Ausdruck für sich anhand der Typisie- rungsregeln überprüft, so dass bei dem Auftreten eines Typfehlers in dem Programm feststellbar ist, an welcher Stelle des Programms der Fehler aufgetreten ist. Somit ist eine genaue Angabe des "fehlerhaften" bzw. un- zulässigen Programmbestandteils und eine entsprechende Fehlermeldung an den Benutzer möglich, wodurch die Fehlerbehebung für den Programmierer erheblich erleichtert wird.
Durch das Verfahren wird es einem Programmierer ermöglicht, in einfa- eher Weise ein Programm wie beispielsweise ein Shaderprogramm unter Verwendung von Funktionen erster Klasse zu programmieren, welches in ein äquivalentes Programm erster Ordnung transformiert werden kann. Um die Transformierbarkeit zu gewährleisten, werden dabei statische Funktionen erster Klasse, welche auch als static first class funetions be- zeichnet werden, zugelassen und dynamische Funktionen erster Klasse nicht akzeptiert. Durch das gezielte und spezifische Zulassen von static first class funetions wird die modulare Entwicklung von Programmen ermöglicht, die alle in Programme erster Ordnung transformiert werden können, welche unabhängig von der die Software ausführenden Hard- wareplattform in geringerer Laufzeit ausgeführt werden können. Somit wird eine höhere Nutzleistung des Computers, beispielsweise beim Ren- dern von 3D-Visualisierungen, gewährleistet.
Vorteilhafte Ausführungsformen der Erfindung sind in den Unteransprü- chen, der Beschreibung und den Figuren beschrieben.
Wenn in der vorliegenden Beschreibung auf ein Programm Bezug genommen wird, kann sich die entsprechende Beschreibung, sofern nicht anders angegeben, auch auf einen Programmteil beziehen. Die Typüberprüfung dient dazu, unter Anwendung vorgegebener Typisierungsregeln jedem Ausdruck des Programms einen Typen zuzuordnen. Die Typüberprüfung kann das Anwenden mehrerer, ein Typsystem definierender Typisierungsregeln umfassen, wobei unterschiedliche Regeln für unterschiedliche Arten von Ausdrücken vorgesehen sind. Die Typisierungsregeln weisen den Ausdrücken des Programms Typen zu, die zum einen aus dem Grundtypen und zusätzlich der Bindungszeit des jeweiligen Ausdrucks bestehen. Wenn in der vorliegenden Beschreibung allgemein auf einen "Typen" Bezug genommen wird, ist damit dementsprechend der durch den Grundtypen und die Bindungszeit gebildete Typ gemeint. Wenn auf einen Grundtypen, z.B. einen Funktionstypen oder Basistypen, "mit" einer statischen oder dynamischen Bindungszeit bzw. einen "statischen" oder "dynamischen" Grundtypen Bezug genommen wird, ist damit ein Typ gemeint, der den jeweiligen Grundtypen und die jeweilige Bindungszeit aufweist. Ebenso ist, wenn auf einen Typen "mit" einem Grundtypen, z.B. "mit" einem Funktionstypen, Bezug genommen wird, ein aus Bindungszeit und Grundtyp bestehender Typ gemeint, dessen Grundtyp durch den jeweiligen Grundtypen gegeben ist. Die Typisierungsregeln des Typsystems umfassen vorzugsweise Typzuordnungsregeln, die angeben, unter welchen Voraussetzungen einem Ausdruck einer bestimmten Art ein bestimmter Typ zugeordnet wird. Ferner umfassen die Regeln vorzugsweise Wohlgeformtheitsregeln, die angeben, unter welchen Voraussetzungen ein Typ als wohlgeformt angenommen wird und dementsprechend verwendet werden darf. Zudem können Sub- typisierungsregeln vorgesehen sein, die angeben, unter welchen Bedingungen ein bestimmter Typ als Subtyp eines anderen Typen angenommen wird. Derartige Typsysteme sind an sich bekannt und beispielsweise in "Types and Programming Languages" von Benjamin C. Pierce, MIT Press, 2002, beschrieben. Gemäß einer Ausführungsform wird eine Fehlermeldung ausgegeben, wenn bei der Typüberprüfung festgestellt wird, dass einem Ausdruck kein Typ zugeordnet werden kann. Dies ist insbesondere dann der Fall, wenn eine auf den jeweiligen Ausdruck anzuwendende Typisierungs- oder
Typzuordnungsregel nicht erfolgreich angewendet werden kann, weil der Ausdruck die durch die Typisierungsregeln vorgegebenen Voraussetzungen nicht erfüllt. Bevorzugt gibt die Fehlermeldung den Ausdruck bzw. Unterausdruck an, der nicht typisiert werden kann. Auf diese Weise kann einem Programmierer der Fehler und auch die genaue Ursache bzw. Stelle in dem Programmcode, die den Fehler verursacht, mitgeteilt werden, so dass der Fehler leicht durch entsprechende Änderung des Programmcodes behoben werden kann. Vorzugsweise wird eine Fehlermeldung ausgegeben, wenn ein Ausdruck mit einem Funktionstypen als mögliches Ergebnis einer dynamischen Fallunterscheidung angegeben ist. Eine Fallunterscheidung umfasst eine Bedingung, von der das Ergebnis der Fallunterscheidung abhängt, und besteht z.B. aus einem if-else-Ausdruck. Bei einer dynamischen Fallun- terscheidung ist das Ergebnis der Fallunterscheidung nicht statisch bekannt, sondern erst zur Laufzeit, z.B. wenn der die Bedingung repräsentierende Ausdruck eine dynamische Bindungszeit aufweist und es somit nicht statisch bekannt ist, ob die Bedingung erfüllt ist oder nicht bzw. ob der die Bedingung repräsentierende Ausdruck wahr oder falsch ist. Wenn nun als mögliche Ergebnisse einer solchen dynamischen Fallunterscheidung, z.B. in den Zweigen eines if-else-Ausdrucks, jeweils Ausdrücke mit einem Funktionstypen angegeben sind, würde aus der Fallunterscheidung eine Funktion resultieren, welche nicht statisch bekannt ist und somit nicht durch partielle Auswertung des Programms vor der Laufzeit elimi- niert werden kann. Dies wird durch die Fehlermeldung angezeigt. Unter einem Ausdruck mit einem Funktionstypen ist im Rahmen der vorstehend beschriebenen Ausführungsform vorzugsweise auch ein Ausdruck zu verstehen, der einen aus einem oder mehreren Typen zusammengesetz- ten Grundtypen aufweist, wobei zumindest einer der Typen, aus denen der Grundtyp zusammengesetzt ist, einen Funktionstypen als Grundtypen aufweist. Ein solcher Typ wird hierin auch als ein einen Funktionstyp "enthaltender" Typ bezeichnet. Zusammengesetzte Grundtypen sind nachstehend noch genauer erläutert.
Bevor auf weitere vorteilhafte Ausführungsformen eingegangen wird, ist nachfolgend zum besseren Verständnis die Syntax einer beispielhaften Programmiersprache in erweiterter Backus-Naur-Form (EBNF) angegeben, welche für die vorliegende Beschreibung relevante Ausdrücke der Programmiersprache formalisiert. Die hier verwendete Syntax entspricht einem einfach getypten λ-Kalkül mit zusätzlichen Bindungszeitannotationen. Dieser Sprachkern kann gegebenenfalls um ein oder mehrere weitere Sprachelemente, d.h. Bindungszeiten, Grundtypen und/ oder Ausdrücke, erweitert werden.
Tabelle 1 (formalisierte Syntax):
T Typen
M D Bindungszeiten
C 1 - Grundtypen
B Basislypen
e c I x I Xx : T. e | e e Ausdrücke
(e , e) I f st e | snd e
if e then e eise e
c konstante Symbole
v c, Xx : T. e (v , ?>) Werte
Γ Γ, x : T Kontexte Jeder Typ T assoziiert einen Grundtypen C mit einer Bindungszeit M. Die Bindungszeit M ist entweder statisch S oder dynamisch D. Die Menge der Grundtypen C umfasst Basistypen B, welche in der obigen Tabelle nicht angegeben sind. Die Basistypen B beschreiben einfache Werte und können zumindest jeweils einen Basistypen für ganzzahlige Zahlenwerte (Basistyp: "int") und Bool'sche Werte (Basistyp: "bool") umfassen. Die Menge der Grundtypen C umfasst außerdem Funktionstypen Ti— >T2 und Paartypen Ti XT2, wobei ein Funktionstyp Ti— >T2 eine Funktion beschreibt, die ein Argument vom Typ Ti (auch Definitionstyp genannt) auf einen Wert vom Typ T2 (auch Zieltyp genannt) abbildet und wobei ein Paartyp Ti XT2 ein Paar von Werten beschreibt, die jeweils einen Wert vom Typ Ti bzw. T2 aufweisen. Grundtypen C, die einen oder mehrere Typen Ti, T2 angeben, d.h. in Tabelle 1 der Funktionstyp Ti— >T2 und der Paartyp Ti XT2, werden im nachfolgenden auch als zusammengesetzte Grundtypen bezeichnet. Typen mit einem zusammengesetzten Grundtypen als Grundtyp werden dementsprechend als zusammengesetzte Typen bezeichnet.
Die in Tabelle 1 angegebene Syntax der Ausdrücke e umfasst Standardsprachelemente. Dazu gehören konstante Symbole c, die in der in Tabelle 1 angegebenen Syntax nicht näher spezifiziert sind und beispiels- weise Operatoren wie Plus (+), Minus (-), logisches Und (and), logisches Oder (or), logisches Nicht (not), Ist-gleich (=), kleiner (<) und größer (>) umfassen können. Ferner umfassen die Ausdrücke e Variablen x und Funktionen bzw. Funktionsdefinitionen, welche durch die Symbolfolge λχ:Τ.ε dargestellt werden, λ symbolisiert, dass es sich um eine Funktions- definition handelt, welche auch als λ-Abstraktion bezeichnet wird. Die Symbolfolge x:T definiert die Variable x als Variable der Funktion, für die der Typ T z.B. vom Benutzer explizit als Typ annotiert worden ist. Das Symbol e symbolisiert den Rumpf der Funktion. Die Ausdruckssyntax umfasst ferner Anwendungen bzw. Applikationen ei e2, die die Anwendung einer Funktion ei auf ein Argument e2 darstellen, Paarkonstruktoren
( ei , e2 ), die ein Paar definieren, Projektionen fst e, snd e, die das erste bzw. zweite Element des Paares e projizieren, und bedingte Ausdrücke
if ep then e eise e' mit der bekannten Bedeutung. Die Menge der Werte v umfasst die konstanten Symbole c, Funktionen bzw. Abstraktionen λχ:Τ.ε und Paare von Werten (v, v).
Ein Typüberprüfungskontext Γ, welcher auch einfach als Kontext bezeichnet wird, ist eine Liste von Paaren, die den Variablen x des Programms jeweils einen Typen zuordnen. Die Symbolfolge x:T bedeutet, dass der Variablen x der Typ T zugeordnet worden ist. Ein Punkt■ bezeichnet den leeren Kontext. Der Einfachheit halber wird im Folgenden in Zusammenhang mit der konkreten Definition der Typisierungsregeln angenommen, dass alle gebundenen Variablen und die freien Variablen des Programms unterschiedliche Bezeichner bzw. Namen haben. Die jeweilige Beschrei- bung ist auch auf Programme anwendbar, bei denen dies nicht der Fall ist, da sich die obige Bedingung stets durch Umbezeichnung gleich bezeichneter, aber unterschiedlicher Variablen gewährleisten lässt.
Ein Programm stellt in der verwendeten Programmiersprache, welche ins- besondere eine λ-Syntax verwendet oder in dieser darstellbar ist, vorzugsweise genau einen Ausdruck dar. Ein Ausdruck besteht typischerweise aus mehreren Unterausdrücken, die wiederum Ausdrücke enthalten können. Die Anwendung der Typzuordnungs regeln auf einen Ausdruck erfordert, dass zunächst rekursiv die Unterausdrücke getypt werden, bis der gesamte Ausdruck typisiert ist oder die Typüberprüfung einen Typfehler ergibt.
Gemäß einer vorteilhaften Ausführungsform wird eine Fehlermeldung ausgegeben, wenn bei der Typüberprüfung festgestellt wird, dass in dem Programm oder in dem Teil des Programms ein Funktionstyp Ti— >T2 annotiert ist, der keine statische Bindungszeit S aufweist. Die Typannotation kann z.B. von der Art x:T sein und dient der Festlegung des Typen T einer Funktionsvariablen x in einer Funktionsdefinition λχ:Τ.ε. Die Typannota- tion wird vorzugsweise manuell vom Programmierer bei der Formulierung des Programms vorgenommen. Durch die vorstehende Maßnahme wird sichergestellt, dass in derartigen Typannotationen nur zulässige Funktionstypen, d.h. Funktionstypen mit statischer Bildungszeit, akzeptiert werden.
Eine explizite Typannotation ermöglicht es, einen Ausdruck, der eine Funktion definiert, unabhängig von den übrigen Ausdrücken des Programms und insbesondere unabhängig von einem Operanden, auf den die Funktion ggf. angewendet wird, auf seinen Typen und seine Zulässigkeit hin zu überprüfen. Zu diesem Zweck wird überprüft, ob der annotierte Typ der Funktionsvariablen selbst zulässig ist und ob der Rumpf der Funktion unter Voraussetzung des annotierten Typen für die Funktionsvariable zulässig ist. Es ist ein grundsätzlicher Vorteil des hierin beschriebenen Verfahrens, dass einzelne Ausdrücke bzw. Programmteile unabhängig von den übrigen Ausdrücken bzw. Programmteilen auf ihren Typen hin überprüft werden können, d.h. ohne dass alle übrigen Programmteile und somit das gesamte Programm gleichzeitig vorliegen müssen. Stattdessen ist es zur
Typüberprüfung eines Ausdrucks in jedem Fall ausreichend, wenn zum Zeitpunkt der Überprüfung nur die Typen der übrigen Ausdrücke bzw. Programmteile bekannt sind. Dadurch wird eine modulare Programmierung und Überprüfung ermöglicht, was die Erstellung zulässiger Programme erheblich erleichtert.
Aufgrund der expliziten Typannotation kann jeweils gesondert überprüft und dem Benutzer im Fehlerfall mitgeteilt werden, ob ein unzulässiger Typ annotiert wurde, d.h. die Funktion unter Voraussetzung eines fehlerhaften Typen definiert wurde, ob der Rumpf der Funktion unter Voraussetzung des annotierten (zulässigen) Typen unzulässig ist oder ob trotz zulässiger Funktionsdefinition die Funktion jedoch in dem Programm auf einen Operanden angewendet wird, welcher nicht den erwarteten annotierten Typen aufweist. Diese getrennte Überprüfung ermöglicht eine modulare Überprüfung und eine aussagekräftige Fehlerdiagnose mit geringem Aufwand.
Die vorstehend beschriebene Vorschrift zur Überprüfung von Typannotationen kann im Fall von Funktionsdefinitionen durch eine entsprechende Typzuordnungsregel realisiert sein, welche auf Funktionsdefinitionen anzuwenden ist, ggf. in Kombination mit einer Wohlgeformtheitsregel, die angibt, unter welcher Voraussetzung ein Typ mit einem Funktionstypen als Grundtyp als wohlgeformt angenommen wird. Nachfolgend sind eine entsprechende Typzuordnungsregel T-LAM beispielhaft angegeben, welche die Voraussetzung umfasst, dass bei einem Ausdruck λχ:Τ.ε der Typ T wohlgeformt ist (ausgedrückt durch T: *), sowie eine Wohlgeformtheitsre- gel WF-FUN, in der die Voraussetzung formuliert ist, dass ein Funktionstyp nur mit statischer Bindungszeit wohlgeformt ist.
T : * Γ. .Γ : 7 Ί , : T'
T h \x : T. e : S (T ->■ T') Mi C : * M2 C2 :★ ,
— — (WF-FUN)
S (M, d -> M2 C2) : *
Prinzipiell sind Regeln gemäß der vorstehenden Schreibweise so zu ver- stehen, dass die oberhalb des waagrechten Trennstriches formulierten, ein oder mehreren Voraussetzungen bei der Anwendung der jeweiligen Regel geprüft werden und die unterhalb des Trennstriches dargestellten, ein oder mehreren Schlussfolgerungen abgeleitet werden, wenn die Voraussetzungen erfüllt sind. Eine Gesamtübersicht bevorzugter Typisierungsre- geln ist in den nachfolgenden, in Zusammenhang mit bevorzugten Aus- führungsbeispielen erläuterten Tabellen 3a, 3b, 3c und 3d enthalten.
Wie vorstehend beschrieben, erleichtert die explizite Typannotation bei der Definition von Funktionsvariablen die Typüberprüfung und erlaubt eine modulare Überprüfung und aussagekräftige Fehlerdiagnose. Das Verfahren kann deshalb verlangen, dass in Funktionsdefinitionen eine wie vorstehend beschriebene explizite Annotation des Typen für jede Funktionsvariable vorgesehen ist, wobei andernfalls z.B. eine Fehlermeldung ausgegeben werden kann. Vorzugsweise wird die Annotation eines vollständigen Typen mit sowohl Grundtypen als auch Bindungszeit der jeweiligen Funktionsvariable verlangt. Zur notationellen Vereinfachung kann es auch zugelassen werden, wenn eine Funktionsdefinition eine explizite Typannotation umfasst, die aber nur den Grundtypen und nicht die Bindungszeit des Typen der Variablen angibt und/ oder wenn die Annotation einen zu- sammengesetzten Grundtypen für die Funktionsvariable angibt und dabei jeweils nur den Grundtypen der Typen angibt, aus denen der zusammengesetzte Grundtyp zusammengesetzt ist, d.h. z.B. x: (int—► int) anstatt x: S (Dint— >Dint). Das Verfahren kann dann die Definition so behandeln, als sei ein zulässiger Standardtyp annotiert worden, welcher den jeweili- gen Grundtypen und eine für diesen Grundtypen zulässige Bindungszeit aufweist. Dabei kann z.B. die statische Bindungszeit für Funktionen und/ oder - soweit zulässig - die dynamische Bindungszeit für alle anderen Typen angenommen werden. Alternativ kann eine Fehlermeldung ausge- geben werden und/ oder eine Aufforderung ausgegeben werden, die Bindungszeit zu annotieren. Gemäß einer Ausführungsform wird zumindest für Funktionstypen eine explizite Annotation der Bindungszeit verlangt.
Gemäß einer Ausführungsform ist auf den Bindungszeiten M eine lineare Ordnung definiert, gemäß der die statische Bindungszeit S kleiner als die dynamische Bindungszeit D ist. Entsprechend der Definition einer solchen Ordnung kann bei der Typüberprüfung zugelassen werden, dass ein Ausdruck mit einer statischen Bindungszeit S auch an einer Stelle in dem Programm verwendet werden kann, an dem ein Ausdruck mit einer dyna- mischen Bindungszeit D erwartet wird, sofern ein entsprechender wohlgeformter Typ mit einer dynamischen Bindungszeit vorhanden ist. Das bedeutet, dass insbesondere Ausdrücke mit einem statischen Basistypen auch verwendet werden können, wenn ein dynamischer Basistyp erwartet wird, während andererseits Funktionsausdrücke nur mit statischer Bin- dungszeit verwendet werden können, da kein wohlgeformter Funktionstyp mit dynamischer Bindungszeit existiert.
Eine solche Ordnung bzw. Reihenfolge kann durch eine Regel wie z.B. die folgende Regel B-STATIC formalisiert sein, deren Anwendbarkeit überprüft wird, wenn in einer Typzuordnungsregel eine bestimmte Ordnung der
Bindungszeiten von Unterausdrücken eines zu typisierenden Ausdrucks als Voraussetzung spezifiziert ist. Die Ordnung der Bindungszeiten ist bevorzugt reflexiv, wie nachfolgend durch die beispielhafte Regel B-REFL formalisiert ist: S <: D (B - STATIC)
M <: M (B- REFL)
Bevorzugt wird bei der Typüberprüfung ein Basistyp B mit jeder Bin- dungszeit S, D als wohlgeformt angenommen. Es können also in dem Programm Variablen verwendet werden, die dynamische Werte des jeweiligen Basistypen, z.B. ganzzahlige dynamische Zahlenwerte oder dynamische Gleitkommazahlenwerte, repräsentieren, ebenso wie Variablen, die statisch bekannte Werte von dem jeweiligen Basistyp repräsentieren. Die Annahme von Basistypen mit jeder Bindungszeit als wohlgeformt ist vorzugsweise in einer Wohlgeformtheitsregel für Basistypen spezifiziert. Eine entsprechende beispielhafte Regel WF-BASE ist nachfolgend angegeben:
M B : -k (WF-BASE)
Gemäß einer vorteilhaften Ausführungsform wird bei der Typüberprüfung ein Typ M(Ti— > T2) mit einem Funktionstypen Ti— > T2 als Grundtyp nur dann als wohlgeformt angenommen, wenn der Funktionstyp einen wohlgeformten Zieltyp T2 und für die ein oder mehreren Variablen der Funktion jeweils einen wohlgeformten Definitionstyp Ti angibt und wenn der Typ M(Ti— > T2) eine statische Bindungszeit S aufweist. Dadurch wird gewährleistet, dass bei der Typüberprüfung ein Funktionstyp nur gemeinsam mit der statischen Bindungszeit verwendet wird. Die vorstehend beschriebene Bedingung kann durch eine Wohlgeformtheitsregel realisiert werden, die angewendet wird, um festzustellen, ob ein Funktionstyp wohlgeformt ist. Diese Wohlgeformtheitsregel kann insbesondere der vorstehend angegebenen Regel WF-FUN entsprechen. Die obige Regel WF-FUN ist auf unäre bzw. einstellige Funktionen anwendbar, d.h. Funktionen, deren Definitionsmenge genau eine Variable umfasst. Prinzipiell lässt sich auch für mehrstellige Funktionen, d.h.
Funktionen mit mehreren Variablen, eine entsprechende Regel aufstellen, die überprüft, ob jeder Definitionstyp ein wohlgeformter Typ ist und ob der Zieltyp wohlgeformt ist, um einen Funktionstypen als wohlgeformt anzunehmen. Da eine mehrstellige Funktion aber immer auch als Ineinander- Schachtelung einer entsprechenden Anzahl von unären Funktionen darstellbar ist, wird bei den hierin konkret als Beispiel formalisierten Regeln der Einfachheit halber von unären Funktionen ausgegangen.
Die Wohlgeformtheitsregeln werden vorzugsweise immer dann angewendet, wenn in einer Funktionsdefinition ein Typ annotiert ist, dessen Wohl- geformtheit zu überprüfen ist, und vorzugsweise dann, wenn einem Aus- druck im Rahmen einer Subtypisierung ein Supertyp zugeordnet werden soll, damit der Ausdruck die Voraussetzungen einer anzuwendenden Typzuordnungsregel erfüllen kann, wie im Weiteren noch erläutert ist.
Gemäß einer Ausführungsform umfasst die Menge der Grundtypen C eine Menge von zusammengesetzten Grundtypen zur Beschreibung von zusammengesetzten Werten, die zumindest einen Paartypen Ti XT2 zur Beschreibung von Paaren von Werten umfasst. Derartige zusammengesetzte Grundtypen zur Beschreibung von zusammengesetzten Werten und insbesondere Paartypen erlauben die Zusammenfassung mehrerer Werte in Paaren, wobei durch Schachtelung mehrerer Paare ineinander die Zusammensetzung einer beliebigen Anzahl von Werten möglich ist, wodurch die Flexibilität der Programmierung erheblich erhöht wird. Ein Grundtyp zur Beschreibung eines zusammengesetzten Werts gibt vorzugsweise jeweils einen Grundtypen für jedes der Elemente bzw. jeden der Werte an, aus denen der zusammengesetzte Wert zusammengesetzt ist. Bevorzugt wird bei der Typüberprüfung ein Typ M (Mi Ci >< M2 C2 ) mit einem Paartypen M1 C1 XM2 C2 als Grundtyp nur dann als wohlgeformt angenommen, wenn die Typen M1 C1 , M2 C2, die die Elemente des Paars be- schreiben, jeweils wohlgeformt sind und Bindungszeiten Mi , M2 aufweisen, die nicht kleiner sind als die Bindungszeit M des Typen
M (Mi Ci X M2 C2 ).
Die Wohlgeformtheit eines Paartypen gemäß der vorstehenden Beschreibung wird vorzugsweise durch Anwenden einer Wohlgeformtheitsregel für Paare überprüft, welche beispielsweise der nachstehend wiedergegebenen Regel WF-PAIR entsprechen kann:
Figure imgf000024_0001
Der Zusammenhang M <: Mi mit i = 1 , 2 bringt dabei zum Ausdruck, dass die Bindungszeiten Mi , M2 nicht kleiner sind als die Bindungszeit M des Paartypen.
Gemäß einer weiteren Ausführungsform wird bei der Typüberprüfung einem Ausdruck λχ:Τ.ε , der eine Funktion mit zumindest einer Funktionsvariablen x definiert und eine Angabe des Typen T jeder Funktionsvariablen x sowie eine Angabe des Rumpfs e der Funktion umfasst, genau dann, wenn der angegebene Typ T jeder Funktionsvariablen x wohlgeformt ist und dem Rumpf e der Funktion in dem Kontext, der den Kontext Γ des Ausdrucks λχ:Τ.ε und die ein oder mehreren Funktionsvariablen x mit dem jeweils angegebenen Typen T jeder Funktionsvariablen x umfasst, ein Typ T zugeordnet wird, ein Funktionstyp T— >T mit statischer Bindungszeit S zugeordnet, welcher die für die eine oder mehreren Funktionsvariablen x angegebenen Typen T als Definitionstypen der Funktion und den dem Rumpf e zugeordneten Typen T als Zieltypen der Funktion angibt.
Die Angabe des Typen T jeder Funktionsvariablen x ist dabei vorzugsweise eine wie vorstehend beschriebene z.B. durch den Programmierer vorgenommene explizite Typannotation. Durch die Zuordnung der statischen Bindungszeit zu dem Funktionstypen unter den obigen Voraussetzung werden Funktionsdefinitionen typisiert und somit zunächst zugelassen, so dass die Programmierung statischer Funktionen erster Klasse ermöglicht wird. Im Zusammenwirken mit den übrigen Typisierungsregeln wird sichergestellt, dass Funktionen nur so verwendet werden, dass sie statisch ausgewertet werden können, und andernfalls ein Typisierungsfehler auf- tritt und eine entsprechende Fehlermeldung ausgegeben werden kann. Beispielsweise wird in Zusammenhang mit der noch zu beschreibenden Typisierungsregel für bedingte Ausdrücke sichergestellt, dass die Verwendung einer Funktionsdefinition als Zweig bzw. Fall in einem bedingten if- else-Ausdruck, welcher eine Bedingung mit einer dynamischen Bindungs- zeit aufweist, zu einem Typfehler führt. Somit wird erkannt, dass der bedingte Ausdruck in diesem Fall nicht durch partielle Auswertung eliminiert werden könnte und das Programm folglich nicht partiell zu einem Programm erster Ordnung ausgewertet werden könnte. Vorzugsweise wird die vorstehend beschriebene Vorschrift durch eine Typzuordnungsregel realisiert, die angewendet wird, wenn eine Funktionsdefinition zu typisieren ist. Eine beispielhafte Regel T-LAM für unäre Funktionsdefinitionen ist nachfolgend angegeben. T : * Γ, χ : Τ h e : Τ'
— (T-LAM)
Γ h Xx : T. e : S (T ->· T')
Die Typrelation Γ h e : T bedeutet, dass dem Ausdruck e in dem Kontext Γ des Ausdrucks der aus Grundtyp und Bindungszeit bestehende Typ T zugeordnet wird. Der Typisierungskontext Γ eines Ausdrucks e enthält vorzugsweise zumindest diejenigen Variablen mit den jeweils zugeordneten Typen, die in den dem jeweiligen Ausdruck übergeordneten Ausdrücken definiert werden, wobei in den beispielhaft angegebenen Typzuordnungs- regeln das Symbol Γ stets den Kontext des jeweiligen mit der Typzuord- nungsregel zu typisierenden Ausdrucks bezeichnet. Die vorstehende Regel T-LAM sagt dementsprechend aus, dass dem Ausdruck λχ:Τ.ε in dem Kontext Γ des Ausdrucks λχ:Τ.ε unter den angegebenen weiteren Voraussetzungen der angegebene Typ zugeordnet wird, wenn dem Ausdruck e in dem Kontext Γ, x:T, d.h. dem Kontext, der den Kontext Γ des Ausdrucks λχ:Τ.ε selbst sowie das zusätzliche Typzuordnungspaar x:T mit der Variablen x und dem Typen T enthält, der Typ T zugeordnet wird.
Wenn in der vorliegenden Beschreibung allgemein darauf Bezug genommen wird, dass einem Ausdruck ein Typ zugeordnet wird bzw. dass über- prüft wird, ob einem Ausdruck ein Typ zugeordnet wird, ist darunter, soweit nicht anders angegeben, vorzugsweise zu verstehen, dass dem Ausdruck in dem Kontext des Ausdrucks der Typ zugeordnet wird.
Gemäß einer weiteren Ausführungsform wird bei der Typüberprüfung einem Ausdruck (ei , e2), der ein Paar definiert, wobei ein erstes Element des Paares durch einen ersten Unterausdruck ei und ein zweites Element des Paares durch einen zweiten Unterausdruck e2 angegeben ist, genau dann, wenn dem ersten Unterausdruck ei ein erster Typ Ti und dem zwei- ten Unterausdruck e2 ein zweiter Typ T2 zugeordnet wird, ein Paartyp (Ti x T2) mit statischer Bindungszeit S zugeordnet, der das erste Element des Paares durch den ersten Typen Ti und das zweite Element des Paares durch den zweiten Typen T2 beschreibt.
Die vorstehende Vorschrift ist vorzugsweise durch eine Typzuordnungsregel realisiert, welche überprüft wird, wenn ein ein Paar definierender Ausdruck zu typisieren ist. Eine solche Regel T-PAIR ist nachfolgend beispielhaft angegeben:
Figure imgf000027_0001
Bevorzugt ist sowohl auf der Menge der Typen T als auch auf der Menge der Grundtypen C jeweils eine reflexive und transitive Subtypbeziehung definiert. Eine Subtypbeziehung legt fest, unter welchen Voraussetzungen ein Typ ein Subtyp eines anderen Typen ist, wobei der letztgenannte Typ dann auch als Supertyp bezeichnet wird. Ist ein Typ ein Subtyp eines anderen Typen, wird im Rahmen der Typüberprüfung ein Ausdruck, dem der Subtyp zugeordnet wird, vorzugsweise auch überall dort zugelassen, wo ein Ausdruck von dem Supertypen zulässig ist bzw. erwartet wird, sofern beide Typen wohlgeformt sind. Die Definition der Subtypbeziehun- gen vereinfacht die Typüberprüfung, da verschiedene Typen mit denselben Typisierungsregeln behandelt werden können. Um zu überprüfen, ob ein Typ ein Subtyp eines anderen Typen ist, können ein oder mehrere Subty- penregeln überprüft und angewendet werden, die definieren, wann ein Typ ein Subtyp eines anderen Typen ist.
Bevorzugt wird ein aus Bindungszeit M und Grundtyp C bestehender erster Typ T = MC genau dann als Subtyp eines zweiten Typen T = M' C an- genommen, wenn die Bindungszeit M des ersten Typen T kleiner oder gleich der Bindungszeit M' des zweiten Typen ist und wenn der Grundtyp C des ersten Typen T ein Subtyp des Grundtypen C des zweiten Typen T ist. Aufgrund der linearen Ordnung der Bindungszeiten mit S <: D gemäß der Regel B-STATIC bedeutet dies, dass ein aus einem Grundtyp und einer statischen Bindungszeit bestehender Typ stets ein Subtyp des denselben Grundtypen und eine dynamische Bindungszeit aufweisenden Typen ist. Durch die obige Subtypbeziehung wird erreicht, dass in dem Programm ein statischer Ausdruck auch stets dort eingesetzt werden kann, wo im Rahmen der Typüberprüfung ein Ausdruck mit einem entsprechenden Grundtypen und einer dynamischen Bindungszeit erwartet wird, sofern beide Typen wohlgeformt sind.
Die vorstehende Vorschrift wird vorzugsweise durch eine Subtypenregel realisiert, die angewendet wird, um zu überprüfen, ob ein Typ ein Subtyp eines anderen Typen ist. Eine solche Regel SUB-TYPE ist nachfolgend beispielhaft angegeben:
M < : M' C ,< : ,C' (SUB-TYPE)
M C <: M' C
Die Notation T<: T bedeutet, dass der Typ T ein Subtyp des Supertypen T ist. Während die vorstehende Vorschrift Subtypenbeziehungen zwischen aus Bindungszeit und Grundtyp bestehenden Typen definiert, sind nachfolgend Subtypenbeziehungen zwischen Grundtypen erläutert.
Bevorzugt wird ein erster Funktionstyp Tn— >Ti2 genau dann als Subtyp eines zweiten Funktionstypen T21— >T22 angenommen, wenn jeder Definitionstyp T21 des zweiten Funktionstypen ein Subtyp des jeweiligen korrespondierenden Definitionstypen Ti 1 des ersten Funktionstypen ist und der Zieltyp T12 des ersten Funktionstypen ein Subtyp des Zieltypen T22 des zweiten Funktionstypen ist. Die Voraussetzung, dass der Definitionstyp T21 des zweiten Funktionstypen ein Subtyp des Definitionstypen Tu des ersten Funktionstypen ist, bedeutet, dass der erste Funktionstyp eine Funktion beschreiben muss, die zumindest diejenigen Argumente bzw. Operanden akzeptiert und verarbeiten kann, die der zweite Funktionstyp akzeptiert und verarbeitet. Die Voraussetzung, dass der Zieltyp T12 des ersten Funktionstypen ein Subtyp des Zieltypen T22 des zweiten Funktionstypen ist, bedeutet, dass der erste Funktionstyp eine Funktion be- schreiben muss, die einen Ausdruck mit einem Typen T12 liefert, der zulässigerweise überall dort verwendet werden darf, wo ein Ausdruck vom Typ T22 erwartet wird.
Die vorstehende Vorschrift wird vorzugsweise durch eine Subtypenregel für Funktionstypen realisiert, die angewendet wird, um zu überprüfen, ob ein Funktionstyp ein Subtyp eines anderen Funktionstypen ist. Eine solche Regel SUB-FUN ist nachfolgend beispielhaft angegeben.
22
(SUB-FUN)
T\\— > T\2 < : T'2\ — T22
Gemäß einer weiteren Ausführungsform wird ein erster Paartyp T11 XT12 genau dann als Subtyp eines zweiten Paartypen T21 XT22 angenommen, wenn der Typ Ti 1 des ersten Elements des ersten Paartypen ein Subtyp des Typen T21 des ersten Elements des zweiten Paartypen ist und der Typ T12 des zweiten Elements des ersten Paartypen ein Subtyp des Typen T22 des zweiten Elements des zweiten Paartypen ist. Dadurch wird es ermöglicht, einen Paartypen dort einzusetzen, wo ein Paartyp erwartet wird, dessen Elemente Supertypen der Typen der Elemente des vorhandenen Paartypen sind. Die vorstehende Vorschrift wird vorzugsweise durch eine Subtypenregel realisiert, die angewendet wird, um zu überprüfen, ob ein Paartyp ein Subtyp eines anderen Paartypen ist. Eine solche Regel SUB- PAIR ist nachfolgend beispielhaft angegeben.
Tlt<:T2i TV2<:T22 (Sub .Pair)
Tu x T\2 < : / j i x / 1>-_>
Gemäß einer vorteilhaften Ausführungsform wird bei der Typüberprüfung einem Ausdruck e, dem ein erster Typ T zugeordnet wird, genau dann ein beliebiger zweiter Typ T zugeordnet, wenn der zweite Typ T wohlgeformt ist und wenn der erste Typ T ein Subtyp des zweiten Typen T ist. Die Definition der Subtypbeziehungen ermöglicht es also, einem Ausdruck, dem ein Typ zugeordnet ist, einen anderen Typen zuzuordnen, welcher ein Supertyp des zweiten Typen ist. Das Erfordernis, dass der zuzuordnende Supertyp T ein wohlgeformter Typ sein muss, stellt dabei sicher, dass ein syntaktisch bestehender Supertyp nicht zugeordnet wird, wenn er nicht wohlgeformt ist, so dass beispielsweise kein Funktionstyp mit einer dynamischen Bindungszeit zugeordnet werden kann.
Die vorstehende Vorschrift ist bevorzugt durch eine Subtypzuordnungsre- gel realisiert, die vorzugsweise überprüft wird, wenn einem Ausdruck ein Typ zugeordnet worden ist, welcher eine Voraussetzung einer für die Typisierung eines übergeordneten Ausdrucks zu überprüfenden Vorschrift nicht erfüllt, um dem Ausdruck möglichst einen Supertypen zuzuordnen, der die Voraussetzung erfüllt. Ist dies nicht möglich, wird vorzugsweise ein Typfehler ausgegeben und eine Fehlermeldung erzeugt. Andernfalls wird der passende Typ zugeordnet, die auf den übergeordneten Ausdruck anzuwendende Typzuordnungsregel angewendet und die Typüberprüfung dadurch fortgesetzt. Eine wie vorstehend beschriebene Subtypzuord- nungsregel T-SUB ist nachfolgend beispielhaft angegeben: Γ h e : T
Die Definition der Subtypen führt somit dazu, dass bei der Typüberprü- fung ein Ausdruck eine durch eine Typzuordnungsvorschrift an seinen Typen gestellte Anforderung immer auch dann erfüllen kann, wenn der ihm zugeordnete Typ ein Subtyp des durch die Typzuordnungsregel geforderten Typen ist und der geforderte Typ wohlgeformt ist. Wenn in der vorliegenden Beschreibung als Voraussetzung der erfolgreichen Anwendung einer Typzuordnungsvorschrift beschrieben ist, dass einem oder mehreren Ausdrücken ein bestimmter Typ zugeordnet wird, ist dies so zu verstehen, dass die jeweilige Vorschrift stattdessen auch verlangen kann, dass den jeweiligen Ausdrücken ein Typ zugeordnet werden muss, der mit dem jeweils bestimmten Typen identisch ist oder ein wohlgeformter Subtyp des bestimmten Typen ist.
Wie vorstehend beschrieben, ist das Typsystem vorzugsweise durch einen Satz von Regeln definiert, welche angewendet werden, um jedem Ausdruck des Programms einen Typen zuzuordnen. Dabei ist vorzugsweise jeder Art von Ausdruck, d.h. insbesondere Funktionsdefinitionen, Paardefinitionen, Funktionsanwendungen, bedingten Ausdrücken etc., eine Typzuordnungsregel zugeordnet, anhand der der Ausdruck überprüft wird, d.h. deren Voraussetzungen überprüft werden und anhand der dem Ausdruck ein Typ zugeordnet wird, wenn die Voraussetzungen der Regel erfüllt sind. Die vorstehend beschriebene Subtypzuordnungsregel stellt eine zusätzliche Regel dar, die vorzugsweise dann auf einen Unterausdruck eines gerade anhand einer zu überprüfenden Typzuordnungsregel überprüften übergeordneten Ausdrucks angewendet wird, wenn der Unterausdruck eine in der Typzuordnungsregel für den übergeordneten Ausdruck spezifi- zierte Voraussetzung bezüglich des Typen des Unterausdrucks nicht erfüllt.
Gemäß einer vorteilhaften Ausführungsform wird bei der Typüberprüfung einem bedingten Ausdruck, dessen Bedingung durch einen ersten Unterausdruck ep angegeben ist und dessen wenigstens zwei Fälle durch einen zweiten und einen dritten Unterausdruck e, e' angegeben sind, wenn dem ersten Unterausdruck ep ein erster Typ Mbool mit einem Bool'schen Grundtyp bool und einer beliebigen ersten Bindungszeit M zugeordnet wird und wenn dem zweiten und dritten Unterausdruck e, e' jeweils ein identischer zweiter Typ M C mit einem beliebigen identischen Grundtypen C und der ersten Bindungszeit M zugeordnet wird, der zweite Typ MC, d.h. der gemeinsame Typ des zweiten und dritten Unterausdrucks e, e', zugeordnet.
Die Typisierung eines bedingten Ausdrucks bzw. Konditionals setzt also voraus, dass die die Fälle bzw. Zweige des Konditionals bildenden Unterausdrücke dieselbe Bindungszeit haben wie der die Bedingung definierende Unterausdruck und die die Fälle bildenden Unterausdrücke gleichzeitig beide denselben Typen haben. In Anbetracht von ggf. definierten Subtyp- beziehungen sind diese Voraussetzungen äquivalent dazu, dass die die beiden Fälle bildenden Unterausdrücke einen gemeinsamen Supertypen haben, der dieselbe Bindungszeit hat wie der die Bedingung bildende Ausdruck.
Die vorstehende Vorschrift ist vorzugsweise durch eine Typzuordnungsregel realisiert, die überprüft wird, wenn ein bedingter Ausdruck zu typisieren ist. Eine solche Regel T-COND ist nachfolgend beispielhaft angegeben. r h e„: bool T h e : M C Γ h e' : M C
(T-COND)
Γ h if ep t en e eise e' : M C
Beispielsweise wird ein bedingter Ausdruck, dessen Bedingung durch einen ersten Unterausdruck angegeben ist und dessen wenigstens zwei Fälle durch einen zweiten und einen dritten Unterausdruck angegeben sind, nicht akzeptiert, wenn dem Bedingungsausdruck eine dynamische Bindungszeit zugeordnet wird und zumindest einem der beiden Fälle ein Funktionstyp als Grundtyp oder ein zusammengesetzter Grundtyp, der einen Funktionstypen enthält, zugeordnet wird.
Eine weitere Ausführungsform sieht vor, dass bei der Typüberprüfung einem Ausdruck ei e2, der eine Anwendung definiert, deren Operator durch einen ersten Unterausdruck ei gebildet ist und deren eine oder mehrere Operanden, welche auch als Argumente bezeichnet werden, je- weils durch einen weiteren Unterausdruck e2 gebildet sind, genau dann, wenn dem Operator ein Funktionstyp T2— >T zugeordnet wird und wenn den ein oder mehreren Operanden jeweils ein Typ T2 zugeordnet wird, der mit dem korrespondierenden Definitionstypen des Funktionstypen T2— >T identisch ist bzw. ein Subtyp desselben ist, der Zieltyp T des Funktionsty- pen T2— >T als Typ zugeordnet wird. Indem überprüft wird, ob dem Operanden ein Typ zugeordnet wird, der dem korrespondierenden Definitionstypen des Funktionstypen entspricht, wird sichergestellt, dass ein Typfehler auftritt, wenn eine Funktion auf einen Operanden angewendet wird, der nicht dem entsprechenden Definitionstypen entspricht, wobei der Definitionstyp, wie vorstehend beschrieben, vorzugsweise durch eine explizite Typannotation bestimmt werden kann.
Beispielsweise kann ein Ausdruck, der eine Anwendung einer Funktion definiert, dann nicht akzeptiert werden, wenn ein Definitionstyp der an- zuwendenden Funktion eine statische Bindungszeit aufweist und dem entsprechenden Operanden, auf den die Funktion angewendet wird, eine dynamische Bindungszeit zugeordnet wird. Vorzugsweise ist die vorstehende Vorschrift durch eine Typzuordnungsregel realisiert, welche überprüft wird, wenn ein eine Funktionsanwendung definierender Ausdruck zu typisieren ist. Eine solche Regel T-APP ist nachfolgend beispielhaft angegeben:
Γ h ei : S (T2—)■ T) Γ h e2 : T2
(T-APP)
Γ 1 h ei e2 : T
Vorzugsweise weist das Programm eine speziell gekennzeichnete Definition einer Einstiegsfunktion auf, bei der die Auswertung des Programms bei der letztendlichen direkten Ausführung auf einem Computersystem be- ginnt. Die Einstiegsfunktion weist vorzugsweise eine oder mehrere Funktionsvariablen auf, die dem Programm bei dessen Aufruf durch ein anderes Programmen übergebene Werte annehmen können, so dass das Programm laufzeitabhängige Ergebnisse erzeugen kann. Vorzugsweise wird auch die Definition der Einstiegsfunktion, wie vorstehend in Bezug auf Funktionen allgemein beschrieben, darauf überprüft, ob sie einen zulässigen Typen aufweist. Als zusätzliche Anforderung an die Einstiegsfunktion wird vorzugsweise überprüft und die Einstiegsfunktion nur akzeptiert, wenn diese keine Funktionsvariablen definiert, die eine statische Bindungszeit aufweisen, d.h. dass insbesondere gefordert sein kann, dass für die einen oder mehreren Variablen der Einstiegsfunktion ein Typ mit einer dynamischen Bindungszeit annotiert ist. Dies ist notwendig, um eine zutreffende Bindungszeitanalyse zu ermöglichen, da die Übergabewerte an die Einstiegsfunktion, d.h. das Programm insgesamt, durch ein aufrufendes Programm im Allgemeinen vor der Laufzeit unbekannt sind. Dementspre- chend darf die Einstiegsfunktion vorzugsweise keine Funktionsvariablen definieren, die einen Funktionstypen aufweisen, da ein Funktionstyp nur mit statischer Bindungszeit zulässig ist, die statische Bindungszeit für die Funktionsvariablen der Einstiegsfunktion aber aus den vorstehenden Gründen bevorzugt nicht zulässig ist. Ferner wird vorzugsweise überprüft und die Einstiegsfunktion nur akzeptiert, wenn deren Rumpf ein Typ zugeordnet wird, der kein Funktionstyp ist bzw. der, z.B. im Falle eines zusammengesetzten Typen, keinen Funktionstypen enthält. Weiterer Gegenstand der Erfindung ist ein Verfahren zur Transformation eines Computerprogramms, das in einer Programmiersprache vorliegt, welche Funktionen erster Klasse unterstützt, bei dem eine Typüberprüfung des Programms oder zumindest eines Teils des Programms durchgeführt wird, um jedem Ausdruck des Programms oder Teils des Programms einen Typen zuzuordnen, der aus einem Grundtypen und einer Bindungszeit besteht, wobei die Menge der Grundtypen mindestens Basistypen zur Beschreibung einfacher Werte und einen Funktionstypen zur Beschreibung von Funktionen umfasst und die Menge der Bindungszeiten mindestens eine statische Bindungszeit und eine dynamische Bindungszeit um- fasst, wobei bei der Typüberprüfung ein Funktionstyp nur gemeinsam mit der statischen Bindungszeit akzeptiert wird. Wenn das Programm oder der Teil des Programms von der Typüberprüfung akzeptiert wird, werden durch partielle Auswertung des Programms oder des Teils des Programms alle in dem Programm oder dem Teil des Programms enthaltenen Funktio- nen erster Klasse eliminiert. Wenn das Programm z.B. einen Ausdruck enthält, der eine Anwendung einer Funktion erster Klasse darstellt, wird der Ausdruck durch partielle Auswertung in einen Ausdruck umgewandelt, der keine Anwendung einer Funktion erster Klasse enthält. Das Verfahren zur Transformation eines Computerprogramms umfasst eine wie vorstehend beschriebene Typüberprüfung des Programms. Die vorstehend in Bezug auf das Verfahren zur Überprüfung und/oder Transformation eines Computerprogramms beschriebenen vorteilhaften Ausfüh- rungsformen und Vorteile gelten entsprechend für das Verfahren zur Transformation des Computerprogramms.
Das Verfahren umfasst, dass das Programm, wenn die Typüberprüfung erfolgreich ist, partiell ausgewertet wird, um das Programm in ein äquiva- lentes Programm ohne Funktionen erster Klasse umzuwandeln. Das partiell ausgewertete Programm erfüllt somit die Funktionalität des ursprünglichen Programms und kann gleichzeitig mit geringerer Laufzeit ausgeführt werden, da die mit der Verwendung von Funktionen erster Klasse verbundenen zusätzlichen Vorgänge wie die Dereferenzierung von Funktionszei- gern und die dynamische Speicherverwaltung nicht notwendig sind. Das Programm kann dementsprechend sogar auf einer Hardware ausgeführt werden, die die vorstehenden Funktionen nicht unterstützt.
Somit können Programme unter Verwendung von Funktionen erster Klas- se entwickelt werden, wodurch die Effizienz der Entwicklung beispielsweise durch Wiederverwendung von Funktionen und einen modularen Pro- grammaufbau gesteigert wird, ohne dass bei der letztendlichen Ausführung des resultierenden Programms auf der Hardware Leistungseinbußen aufgrund von Funktionen erster Klasse auftreten. Durch das beschriebene Überprüfungsverfahren kann mit geringem Zeitaufwand zuverlässig festgestellt werden, ob ein gegebenes Programm in der beschriebenen Weise transformierbar ist, wobei andernfalls eine präzise Aussage über die Ursache des Fehlers in dem Programm getroffen und dem Benutzer angezeigt wird, so dass der Fehler leicht behoben werden kann und die Programmie- rung zulässiger, d.h. transformierbarer, Programme mit geringem Aufwand möglich ist.
Die partielle Auswertung kann das Anwenden der Semantik der Program- miersprache auf die in dem Programm enthaltenen Ausdrücke umfassen, wobei Unterausdrücke ausgewertet werden, deren Wert statisch bekannt ist. Die partielle Auswertung kann z.B. die Inline- Expansion des Rumpfs einer Funktion aus einer Funktionsdefinition in einem die Funktion aufrufenden Anwendungs-Ausdruck umfassen. Geeignete Verfahren zur par- tiellen Auswertung sind an sich bekannt und beispielsweise in "Partial evaluation and automatic program generation" von Neil Jones, Prentice Hall International 1993 beschrieben.
Zunächst, d.h. insbesondere vor einer endgültigen Kompilierung und/oder Assemblierung, kann das ursprüngliche Programm in ein partiell ausgewertetes Programm übersetzt werden, das in einer Programmiersprache vorliegt, die der Programmiersprache des ursprünglichen Programms entsprechen kann und/ oder die eine höhere und/ oder auf der Hochsprachenebene angesiedelte Programmiersprache sein kann. Die partielle Auswertung kann durch Interpretation des ursprünglichen Computerprogramms durchgeführt werden.
Das partiell ausgewertete Programm bzw. das Programm mit dem partiell ausgewerteten Ausdruck wird vorzugsweise in einen von einem Zielcom- putersystem direkt ausführbaren Maschinencode, bevorzugt auf Befehlssatzebene, übersetzt. Dazu kann das partiell ausgewertete Programm durch einen Compiler kompiliert und anschließend gegebenenfalls durch einen Assembler assembliert werden. Anschließend kann das assemblierte Programm durch ein Zielcomputersystem direkt ausgeführt werden. Bei dem Zielcomputersystem kann es sich um ein anderes Computersystem handeln, als das, auf dem die Überprüfung und/ oder die partielle Auswertung und/ oder Kompilierung und/ oder Assemblierung durchgeführt wird, prinzipiell kann aber auch dasselbe Computersystem verwendet werden. Gemäß einer Ausführungsform wird das Programm mit dem partiell aus- gewerteten Ausdruck bzw. das partiell ausgewertete Programm in einen Maschinencode für eine Hardwareplattform übersetzt, die keine Unterstützung für Funktionszeiger bietet und/ oder die keine Unterstützung für eine dynamische Speicherverwaltung bietet. Im Ergebnis erfolgt somit eine vollständige Auswertung des ursprünglichen Computerprogramms entsprechend der der Programmiersprache des ursprünglichen Programms zugrunde liegenden Auswertungssemantik, wobei zunächst eine statische, d.h. zur Übersetzungszeit erfolgende, partielle Auswertung erfolgt und anschließend die restliche dynamische, d.h. zur Laufzeit bzw. Ausführungszeit erfolgende, Auswertung des partiell ausgewerteten Programms, wobei die restliche Auswertung bevorzugt durch direkte Ausführung eines aus dem partiell ausgewerteten Programm erzeugten Maschinencodes erfolgt. Das bzw. die erfindungsgemäßen Verfahren können jeweils prinzipiell auf einem oder mehreren, z.B. als Personal Computer ausgebildeten, Computersystemen durchgeführt werden. Bei dem Programm handelt es sich vorzugsweise um ein Shaderprogramm zur 3D-Visualisierung, welches, ggf. nach der Transformation, von einem Prozessor, insbesondere einem Grafikprozessor, direkt ausgeführt werden kann, um eine dreidimensionale Grafik zu erzeugen und vorzugsweise auf einer Anzeigeeinheit anzuzeigen, während die Überprüfung, Transformation, Kompilierung und/oder Assemblierung auf einem Allzweck-Prozessor durchgeführt werden kann. Die Erzeugung der Grafiken kann insbesondere in Echtzeit erfolgen. Nachfolgend wird die Erfindung anhand mehrerer Beispiele erläutert.
Die Syntax der Programmiersprache, die vorzugsweise auf dem λ-Kalkül basiert, ist eingangs erläutert und in Tabelle 1 dargestellt. Basierend auf der Syntax ist eine Auswertungssemantik gemäß den nachstehend in Tabelle 2 wiedergegebenen Semantikregeln der Programmiersprache definiert.
Tabelle 2 (Semantik):
62
(E-ÄPPl) (E-APP2)
ei e2 "1 e2 vi 62 vi
XxiT.ev = c.[x ·— u] (E-ABSAPP)
-PRFAPP)
Vi t'2 (E
= * V ei => et e2 e2
(E-TUPl) — (E-Tül'2)
(ci,C2) => ( ,e2) (t'i,C2) =ί> (ui,e2) e = e' 7 (E-FSTARG) fst Ct'i ,t'2) =^ t'l (E-FST)
fst e =^ fst e'
(E-SNDARG) snd (t,"i,t2) =>- t'2 (E-SND)
snd e =^ snd e' ei = el
CE-CONDPRED)
if ei then e2 eise e,3 =>· if t'j then t'2 eise e.3 if true then e2 eise 63 => e2 (E-CONDTRUE)
if false then e2 eise f'3 = 63 (E-CONDFALSE) Die Notation e => e bedeutet, dass der linke Ausdruck e zu dem rechten Ausdruck e ausgewertet wird. Die angegebene Semantik entspricht einer Call-by-Value-Semantik. In der Auswertungsregel E-ABSAPP für Anwendungen ei e2 von Funktionen in Tabelle 2 wird die Substitutionsformel e [x i— > v] verwendet. Diese bedeutet, dass jedes freie Auftreten der Variablen x in dem Ausdruck e durch den Wert v ersetzt wird.
Nachstehend in den Tabellen 3a, b, c, d sind die der Typüberprüfung zugrunde liegenden Typisierungsregeln angegeben. Die Regeln in Tabelle 3a bestimmen die lineare Ordnung der Bindungszeiten, die Regeln in Tabelle 3b bestimmen die Wohlgeformtheit von Typen, die Regeln in Tabelle 3c bestimmen Subtyp-Beziehungen zwischen verschiedenen Typen und zwischen verschiedenen Grundtypen und die Regeln in Tabelle 3d bestimmen die Typzuordnung zu den Programmausdrücken.
Tabelle 3a (lineare Ordnung Bindungszeiten)
I M <: M
M <: M (B -REFL)
S <: D (B -STATIC)
Tabelle 3b (Wohlgeformtheitsregeln):
T : *
M B : -k (WF-BASE)
i Ct :★ M2 C2 :★
(WF-FUN)
S (Mt d -+ M2 C2 ) : *
M d -. -k . /- C : M ■ : M,
(WF-PAIR)
M {Mi Ci x M2 C2) : * Tabelle 3c (Subtypisierungsregeln):
T <:T\\C <:C\
M<:M' C<:C" (SUB-TYPE)
MC <:M' C
B <: B (SUB-BASE)
Figure imgf000041_0001
Ί ι <: Ί ι \2 <: Ί 2
(SUB-PAIR)
Τ\ X Τ\2 <· T'l\ X Τ'2'2
Tabelle 3d (Typzuordnungs- Regeln):
Γ h e :
Fhe:T T':* T <:T' (T-SUB)
Γ h e : '
x :T e Γ (T-VAR)
Γ h a; : T
T€ type(c)
(T-CONST)
Γ h c : Γ
T : * r,x:The:T'
: — (T-LAM)
Γ h Äx:T.e : S (Γ— )· T )
Figure imgf000042_0001
Γ h e : (Ί x T2)
(T-PRJI)
Γ h f st e : Ti
Figure imgf000042_0002
snd e : o
I' -.„ : \/bool The: MC Tl·e' MC
(T-COND)
Γ h if e„ then e eise e' : M C
Die Regeln für die Ordnung der Bindungszeiten gemäß Tabelle 3a sowie die Regeln für die Überprüfung der Wohlgeformtheit von Typen gemäß Tabelle 3b und die Regeln für die Überprüfung des Vorliegens einer Sub- typ-Beziehung mit Ausnahme der Regel SUB-BASE sind in der vorstehenden allgemeinen Beschreibung erläutert. Die Regel SUB-Base beschreibt, dass ein Basistyp stets nur sich selbst als Super- bzw. Subtyp hat, so dass Basistypen im vorliegenden Ausführungsbeispiel nicht miteinander austauschbar sind.
Die Typzuordnungsregeln gemäß Tabelle 3d sind mit Ausnahme der Re- geln T-VAR, T-CONST, T-PRJ1 und T-PRJ2 in der vorstehenden allgemeinen Beschreibung erläutert.
Die Regel T-VAR ordnet dem Auftreten einer Variable x in einem Ausdruck den Typen T zu, wenn der jeweilige Kontext Γ eine entsprechende Typzu- Ordnung bzw. Typannotation x:T enthält. Die Regel T-VAR dient also dazu, in dem Kontext Γ nachzusehen, ob für die Variable x in dem Kontext Γ der Typ T annotiert ist und der Variablen x in diesem Fall diesen Typen T zuzuordnen. Die Regel T-VAR wird angewendet, wenn eine Variable in einem übergeordneten Ausdruck auftritt und deren Typ für die Anwen- dung einer für die Typisierung des übergeordneten Ausdrucks anzuwendenden Typisierungsregel erheblich ist.
Die Regeln T-PRJ 1 und T-PRJ2 sind zur Typisierung von Ausdrücken anzuwenden, die eine Projektion eines Paares darstellen, d.h. auf Ausdrü- cke der Art fste, snd e, wobei der Ausdruck fste die Projektion auf das erste Element ei eines Paares (ei , e2) bedeutet und der Ausdruck snd e die Projektion auf das zweite Element e2 eines Paares (ei , e2) bedeutet (siehe die Auswertungsregeln E-FSTARG, E-FST, E-SNDARG, E-SND in Tabelle 2). Die Typzuordnungsregeln T-PRJ 1 und T-PRJ2 bestimmen, dass einem solchen Ausdruck der Typ zugeordnet wird, der dem jeweiligen, d.h. dem ersten bzw. zweiten, Element des Paares zugeordnet wird.
Die Regel T-CONST wird auf konstante Symbole c angewendet und ordnet einem konstanten Symbol c einen Typen T zu, der in der Zuordnungsta- belle type(c) (siehe nachfolgende Tabelle 4) als möglicher Typ dieses Symbols angegeben ist.
Tabelle 4 (Typzuordnungstabelle type(c) für konstante Symbole): ceB.type(c) = {Sbool}
ce . type(c) = {S int}
{S (S bool ->· S bool), 5 (Z? bool D bool
S (5 (Sbool x 5 bool) ->· Sbool),
c G {and, or}. type(c)
S (D (D bool x D bool) D bool)
S (S (S int x S int) ^ Sbool),
ce {=,<}. typc(c)
5' (D (ü int x i int) -· L»bool)
S(S(Sint x Sint) int),
c 6 {+,-}. type(c)
S (D (D int X D int)— D int)
In Tabelle 4 sind die Typen für Bool'sche Konstanten aus der Menge B (true und false), für ganzzahlige Zahlenwerte aus der Menge Z, d.h. Konstanten vom Typ int (...,-1,0, 1,...), und für die Operatoren not, and, or, =, <, +, - angegeben, welche konstante primitive Funktionen darstellen, die in der üblichen Weise definiert sind.
Da konstante Symbole nicht weiter ausgewertet werden und deren Werte statisch bekannt sind, ist den konstanten Symbolen die statische Bindungszeit S zugeordnet. Für die funktionswertigen Operatoren sind in type (c) jeweils zwei unterschiedliche Funktionstypen vorgesehen, nämlich jeweils zum einen ein Funktionstyp, der eine Funktion beschreibt, die von einem statischen Typen auf einen statischen Typ abbildet, und zum ande- ren ein Funktionstyp, der eine Funktion beschreibt, die von einem dynamischen Typen auf einen dynamischen Typen abbildet. Dadurch wird der Tatsache Rechnung getragen, dass die primitiven Funktionen sowohl auf statische Argumente angewendet werden können, in welchem Fall sie statische Werte liefern, als auch auf dynamische Werte, in welchem Fall sie dynamische Werte liefern. Bei der Typ Überprüfung wird der jeweiligen Operatorkonstante derjenige Typ zugeordnet, welcher von der auf den jeweils übergeordneten Ausdruck, der den Operator enthält, anzuwendenden Typisierungsregel erwartet wird, um zu überprüfen, ob die Typisie- rungsregel erfolgreich angewendet werden kann.
In der nachfolgenden Tabelle 5 sind die Auswertungsregeln angegeben, gemäß denen die partielle Auswertung erfolgt.
Tabelle 5 (Regeln partielle Auswertung)
νε \ = c
VE M = x ) = c
Figure imgf000045_0001
^ [(ei . ex ) ] = (V letj , V le2} )
ex if Ve fej = (ei j e2)
fst VE [fei eise
Figure imgf000045_0002
VE |if ep then et eise ej = e if VE [ePl then
Figure imgf000045_0003
eise f |ee] eise
Das Symbol Iel bedeutet, dass der Ausdruck e partiell ausgewertet wird, und die rechte Seite der Gleichungen gibt jeweils das Ergebnis der partiellen Auswertung an. Die geschweiften Klammern auf der rechten Seite der Gleichungen dienen jeweils der Fallunterscheidung. Die der partiellen Auswertung zugrunde liegende Semantik entspricht der in Tabelle 2 angegebenen Semantik der Programmiersprache. Durch die Formel δ (ei , e2) wird die Anwendung eines Funktionssymbols bzw. Operators auf ein oder mehrere konstante Argumente durch einen konstanten Wert ersetzt, d.h. z.B. 5 (not, true) = false und 6 ( + , (41 , 1 )) = 42.
Nachstehend ist die Typisierung von Programmen unter Verwendung der vorstehenden Regeln und Tabellen anhand mehrerer Beispiele erklärt.
Beispiel 1 :
Das erste Beispiel betrifft die in dem eingangs angegebenen Programm- code 1 definierten Funktionen add, sub und apply. Das nachfolgende Regel-Anwendungsdiagramm 1 zeigt, welche Typisierungsregeln auf welche Ausdrücke angewendet werden, um diese Funktionen zu typisieren.
Für die Typüberprüfung wird das in dem Programmcode 1 in einer C- artigen Syntax dargestellte Programm in der in Tabelle 1 definierten λ-
Syntax dargestellt. In dieser Darstellung ergeben sich die Definitionen der Funktionen add, sub und apply zu:
Programmcode 4: add = Xa : D int. Xb : D int. + (α , b)
sub = Xa : D int. Xb : D int. - ( ,6)
apply = Xf : S (D int - S (D int D int)). Xa : D int. Xb : D int. (/ a) b Die in dem ursprünglichen Programmcode 1 als Funktion mit drei Funktionsvariablen f, a, b dargestellte Funktion apply ist in dem λ-Kalkül durch drei ineinander geschachtelte Funktionen mit jeweils einer Funktionsvariablen f bzw. a bzw. b dargestellt, da in der vorliegenden Darstellung von unären Funktionen ausgegangen wird. Ebenso sind die Funktionen add und sub jeweils als zwei ineinander geschachtelte Funktionen mit jeweils einer Funktionsvariablen a bzw. b dargestellt. Für die Variablen a und b, für die zwar explizit ein Grundtyp (int), jedoch keine Bindungszeit annotiert ist, wird die dynamische Bindungszeit angenommen, da für den Grundtypen int die dynamische Bindungszeit grundsätzlich zulässig ist. Für die Variable f der Funktion apply, für die ein Funktionstyp als Grundtyp aber keine Bindungszeit explizit annotiert ist, wird die Bindungszeit S angenommen, da für Funktionstypen nur die statische Bindungszeit zulässig ist. Prinzipiell könnte der Benutzer im Rahmen des Verfahrens auch aufgefordert werden, eine explizite Bindungszeitannotation für die Variab- len, a, b und/oder f vorzunehmen. Der in der C-Syntax in Programmcode 1 ebenfalls annotierte Zieltyp der Funktionen add, sub und apply ist im vorliegenden Ausführungsbeispiel unbeachtlich und wird ignoriert.
Regelanwendungsdiagramm 1 (Teil 1/4) add
add = Aa:Dint.A&:Z)int.+ (a,b)
S (D (D int x D int)—> D int ) £ typc(+) a : D int, b : D int h + : S (D (D int x D int) ->■ D int) sub
sub = Xa : D int . Xb : D int . - (a,b) Ähnlich.
apply
Der Kalkül unterstützt nur unäre Funktionsdefinitionen. Aus apply wird
apply = Xf:S(D int -» S (D int -» D int)). Aa:D int. A6: D int. (/ a) b
(WF-BASE) -=— (WF-BASE)
„ , D int :★ D int :★
(WF-BASE) — 77 . \
D int : * 5 (D int -4 D int) : *
S {D int S(D int -* D int)) : *
· h A/:5(Dint - S(D±nt -> Dint)). where Γ = / : S (D int ->· S (D int -> £> int)), o : D int, i> : D int Regelanwendungsdiagramm 1 (Teil 2/4)
Figure imgf000049_0001
Regelanwendungsdiagramm 1 (Teil 3/4) cd
<
Figure imgf000050_0001
Regelanwendungsdiagramm 1 (Teil 4/4)
(B -REFL) — — : (SUB-BASE)
D <: D int <: int ^ „ ' — — (SUB-TYPE)
D int <: D int ,„ .
(B -STATIC)— — — — — — (SUB-PAIR)
S <: D D int x D int <: D int x D int rc, _ (SUB-TYPE)
S {D int x D int) <: D (D int x D int)
Wie aus Diagramm 1 ersichtlich, lassen sich die Funktionen add und sub erfolgreich typisieren. Die Typisierung der Funktion sub ist in dem Diagramm nicht dargestellt, da sie der Typisierung der insofern äquivalenten Funktion add entspricht. Den Funktionen add und sub wird der Typ S (Dint— >S (Dint— >Dint)) zugeordnet, d.h. es wird festgelegt, dass die Funktionen add und sub jeweils statisch zu verwenden sind und es wird erkannt, dass die Funktionen add und sub jeweils einen dynamischen Wert vom Grundtyp int (Definitionstyp) auf eine statische Funktion (Ziel- typ) abbilden, welche einen dynamischen Wert vom Grundtyp int auf einen dynamischen Wert vom Grundtyp int abbildet. Der Funktionstyp als Zieltyp ergibt sich dabei aufgrund der Betrachtung der Funktionen add und sub als zwei ineinander geschachtelte unäre Funktion anstatt einer zweistelligen Funktion.
Auch die Funktion apply wird erfolgreich typisiert, d.h. es wird erkannt, dass die Funktion apply, wie eingangs beschrieben, durch partielle Auswertung in eine Funktion erster Ordnung transformiert werden kann. Ausschlaggebend ist dabei, dass die Variable f in dem Rumpf der Funktion apply nicht als Teil eines Ausdrucks verwendet wird, der einen dynamischen Typen für f erfordert. Stattdessen fordert die Definition der Funktion apply die Übergabe einer statischen Funktionsvariablen, so dass sichergestellt ist, dass der Wert der Funktion f an der Stelle der Funktionsanwendung (f a) b (λ-Schreibweise) statisch bekannt ist. Zu berücksichti- gen ist dabei, dass in dem Programmcode 1 nicht die Funktion apply, sondern die Funktion foo die Einstiegsfunktion darstellt. Andernfalls müsste die Funktion apply ggf. die zusätzliche Bedingung erfüllen, dass sie keine statischen Funktionsvariablen haben darf, so dass die Annotation der Variablen f als statische Funktion zu einem Typfehler und folglich einer Fehlermeldung für den Benutzer führen würde. Beispiel 2:
Der nachfolgende Programmcode 5 stellt ein weiteres Programm dar, wel- ches mit dem Verfahren überprüft wird.
Programmcode 5: int apply ( static ((int , int) => int) f , int a, int b) {
return f (a , b) ;
}
int add ( int a, int b) { return a + b; }
int sub ( int a, int b) { return a - b; }
int main( int a, int b) i
static ((int , int) => int) f ;
if (true) ■{
f = add;
} eise {
f = sub ;
}
return apply (f , a , b) ;
>
Die Definition der Funktion apply entspricht der Definition der Funktion apply in dem Programmcode 1 bzw. Programmcode 4, wobei in dem Programmcode 5 im Unterschied zu dem Programmcode 1 für die Variable f nicht nur der Funktionstyp als Grundtyp, sondern auch die für Funkti- onstypen vorgeschriebene statische Bindungszeit explizit annotiert ist. Die Funktion "main" ist durch ihren Namen als Einstiegsfunktion gekennzeichnet. Die Variablen a, b in den Funktionen apply, add, sub und main haben keine explizite Bindungszeitannotation. Den Variablen a und b muss aber eine dynamische Bindungszeit zugeordnet werden, damit das Programm zulässig sein kann, da die Einstiegsfunktion keine statischen Funktionsvariablen definieren darf. Der nachfolgende Programmcode 6 gibt das Programm gemäß Programmcode 5 in der Notation des λ-Kalküls an, wobei die dynamischen Bindungszeiten der Variablen a, b vereinfachend weg gelassen sind. Programmcode 6: l et app ly = Af : S ( int— S ( int— int ) ) . Aa : int . Ab : int . f ( a , b ) in l et add = Aa : int . Ab : int . a+b in
l et sub = Aa : int . Ab : int . a -b in
Aa : i nt . Ab : i nt .
l et f = i f t rue then add e i s e sub in
app ly f a b
Die Notation "let x = ei in e2M dient der einfacheren Darstellung und ist äquivalent zu der Notation (λχ:Τ.ε2)ει mit dem jeweils passenden Typen T von ei, wobei der Typ T von ei nicht explizit annotiert ist, sondern durch die Typüberprüfung ermittelt wird, d.h. der Typ T ergibt sich implizit aus dem Programm und konkret aus der Typ Überprüfung des Ausdrucks ei, sofern das Programm zulässig ist.
Das Programm gemäß Programmcode 5 und 6 ist durch partielle Auswertung in ein Programm ohne Funktionen erster Klasse transformierbar. Der bedingte Ausdruck if true then add eise sub in Programmcode 6 kann nämlich statisch zu add ausgewertet werden, so dass die Variable f an der Stelle ihres Aufrufs im Rahmen der Funktion apply statisch bekannt ist. Somit ist die Typüberprüfung erfolgreich und das Programm wird zugelassen. Die entsprechende, vorliegend nicht im Einzelnen dargestellte
Typüberprüfung umfasst die Überprüfung der Regel T-COND für den bedingten Ausdruck if true then add eise sub. Zum Zeitpunkt der Anwen- dung der Regel T-COND ist dabei den Ausdrücken add und sub bereits durch die Regel T-VAR ein Typ mit einer statischen Bindungszeit zugeordnet worden. Da auch der Bedingung des obigen bedingten Ausdrucks, d.h. der Konstante "true", gemäß der in Tabelle 4 angegebenen Vorschrift type (c) der Typ Sbool und damit eine statische Bindungszeit zugeordnet wird, ist die Voraussetzung der Regel T-COND erfüllt, dass die Bedingung und die beiden Fälle des bedingten Ausdrucks dieselbe Bindungszeit auf- weisen müssen, so dass die Regel erfolgreich angewendet wird und die Typisierung weiter fortfährt.
Auf die erfolgreiche Typüberprüfung folgt die partielle Auswertung des Programms. Dazu werden alle Funktionsdefinitionen in den Rumpf der Einstiegsfunktion main durch Inlining hineingefaltet und der Rumpf der Funktion main dadurch vereinfacht. Außerdem wird durch die partielle Auswertung der bedingte Ausdruck aufgelöst. Wenn die Variablen a, b der Einstiegsfunktion eine dynamische Bindungszeit aufweisen, wovon vorliegend ausgegangen wird, und der Zieltyp der Einstiegsfunktion dynamisch ist, enthält die durch die partielle Auswertung vereinfachte Einstiegsfunktion keine weiteren Ausdrücke. Die partielle Auswertung führt zu dem äquivalenten, partiell ausgewerteten Programm, welches nachfolgend als Programmcode 7 wiedergegeben ist. Programmcode 7:
Äa : int . Ab : int . a+b
Dieses vereinfachte Programm kann anschließend in einen Maschinencode für eine beliebige Hardware umgewandelt bzw. übersetzt werden und von der jeweiligen Hardware mit geringer Laufzeit ausgeführt werden, unabhängig davon, ob die Hardware Funktionszeiger oder dynamische Speicherverwaltung unterstützt.
Beispiel 3: Das nachfolgende Beispiel veranschaulicht einen Typfehler, der auftritt, wenn ein Programm mit einer Funktion erster Klasse nicht durch partielle Auswertung in ein äquivalentes Programm erster Ordnung transformierbar ist.
Programmcode 8:
int bar ( bool , int a) {
if (p) {
f = f unct i on ( i nt x) { return x; };
} eise {
f = f un ct i on ( i nt x) -£ return 0-x; };
}
return f (a) ;
} In der λ-Syntax ergibt sich daraus der folgende Programmcode:
Programmcode 9: bar— \p D bool. Xa: D int.
let f = if p
Figure imgf000056_0001
in f a
Die in Programmcode 8 nicht explizit annotierten Bindungszeiten für die Variable p vom Grundtyp bool und die Variablen a, x vom Grundtyp int werden durch das Verfahren als dynamisch angenommen, so wie es in Programmcode 9 explizit notiert ist.
Ähnlich zu den Funktionen add und sub in dem vorstehenden Regelanwendungsdiagramm 1 führt die Typüberprüfung der Ausdrücke λχ : D int. x und λχ : D int. 0 - x nach mehreren Regelanwendungen zu der erfolgreichen Anwendung der Regel T-LAM mit dem nachstehenden Ergebnis: p : D bool, a : D int h λχ : D int. x : S (D int— D int) p : D bool, a : D int h λχ: D int.0 - x : S (D int ->■ D int)
Die Typüberprüfung stellt also fest, dass die Funktionsdefinitionen λχ : D int. x und λχ : D int. 0 - x jeweils statische Funktionen beschreiben, die einen dynamischen Integer-Wert auf einen dynamischen Integer-Wert abbilden.
Der diesen Funktionsdefinitionen nächstübergeordnete Ausdruck ist der bedingte if-else-Ausdruck, der mit der Regel T-COND zu überprüfen ist. Da dem Ausdruck p, welcher die Bedingung des bedingten Ausdrucks darstellt, eine dynamische Bindungszeit zugeordnet wurde und die Regel T-COND verlangt, dass die Bedingung und die Fälle des bedingten Ausdrucks dieselbe Bindungszeit aufweisen, müsste die erfolgreiche Anwen- dung der Regel T-COND die folgende Form annehmen:
Γ h p : D bool Γ h et : D C Γ h ee : D C ^
— —— (T-COND)
Γ h if p then et eise ee : D C
wobei:
Γ = p : D bool, a : D int
Figure imgf000057_0001
Allerdings ist aufgrund der Anwendung der Regel T-LAM bekannt, dass Γ h et : S (D int— >■ D int) j d.h. dass der Ausdruck et eine statische Bindungszeit aufweist. Dasselbe gilt für ee. Um zu überprüfen, ob die Regel T-COND dennoch erfolgreich angewendet werden kann, wird überprüft, ob einem oder mehreren der Ausdrücke p, et oder ee durch Subtyping ein Supertyp zugeordnet werden kann, der die Anwendung der Regel ermöglicht. Da der Typ Dbool außer sich selbst keinen Supertypen aufweist, kommt es darauf an, ob einem der Ausdrücke et oder ee ein geeigneter Supertyp zugeordnet werden kann. Dazu wird ein hypothetischer Supertyp D C mit einer dynamischen Bindungszeit angenommen, der in die Regel T-SUB eingesetzt wird, so dass sich für diese folgende Form ergibt:
Γ h et : S ( D int D int) D C : * S (D int—► D int) < : D C
Aus den Subtypenregeln und insbesondere der Regel SUB-FUN ergibt sich aber, dass zu dem Typen S (Dint— >Dint) kein wohlgeformter Supertyp mit einer dynamischen Bindungszeit existiert, d.h. die Bedingung DC : * nicht erfüllbar ist. Somit sind die Regeln T-SUB und T-COND nicht erfolgreich anwendbar und der bedingte if-else-Ausdruck kann nicht erfolgreich typisiert werden. Es wird dadurch erkannt, dass das Programm nicht in ein äquivalentes Programm erster Ordnung umgewandelt werden kann, weil die in der Funktionsanwendung f a anzuwendende Funktion in dynamischer Weise von der dynamischen Bool'schen Variablen p abhängt. Auf diese Erkennung hin wird ein entsprechender Hinweis an den Benutzer ausgegeben. In dem Hinweis wird dem Benutzer der Ausdruck des Programms mitgeteilt, an dem der Typfehler aufgetreten ist, d.h. vorliegend der bedingte if-else-Ausdruck, so dass das Problem einfach und gezielt behoben und das Programm in ein transformierbares und somit zulässiges Programm umgewandelt werden kann. Die nachfolgend beschriebene einzige Figur zeigt ein Flussdiagramm, welches ein Verfahren zur Überprüfung und Transformation eines Computerprogramms gemäß einer Ausführungsform der Erfindung veranschaulicht. Die runden Felder kennzeichnen jeweils Eingangs- bzw. Ausgangsgrößen des Verfahrens und die eckigen Felder kennzeichnen unter Verwendung der jeweiligen Eingangsgrößen bzw. unter Erzeugung der jeweiligen Ausgangsgrößen durchgeführte Verfahrensschritte.
Ein Programm 10 liegt in einer höheren Programmiersprache vor, die Funktionen erster Klasse unterstützt. In einem Verfahrensschritt 12 wird eine Typüberprüfung des Programms 10 durchgeführt, um jedem Ausdruck des Programms einen Typen zuzuordnen, der einen Grundtypen und eine Bindungszeit des Ausdrucks umfasst, wobei bei der Typüberprüfung ein Funktionstyp nur mit einer statischen Bindungszeit akzeptiert wird.
Ist die Typüberprüfung erfolgreich, d.h. dass das Programm mit Funktionstypen mit statischer Bindungszeit vollständig typisiert werden kann, folgt in einem weiteren Verfahrensschritt 14 die partielle Auswertung des Programms. Ist die Typüberprüfung nicht erfolgreich, wird eine Fehlermeldung 16 erzeugt und beispielsweise über eine Anzeigeeinrichtung des das Verfahren durchführenden Computersystems an einen Benutzer ausgegeben, wobei die Fehlermeldung die Ursache des Fehlers angibt. Die partielle Auswertung 14 transformiert das Programm in ein äquivalentes Programm erster Ordnung, d.h. ohne Funktionen erster Klasse. Anschließend wird das nach wie vor auf der Hochsprachenebene vorliegende partiell ausgewertete Programm in einem Verfahrensschritt 18 durch Kompilieren und Assemblieren in ein Zielprogramm 20 für eine Hardware übersetzt, auf der das Zielprogramm 20 dann vorzugsweise direkt ausge- führt wird.
Bezugszeichenliste Computerprogramm
Typüberprüfung
partielle Auswertung
Fehlermeldung
Kompilieren und Assemblieren
Zielprogramm

Claims

Patentansprüche
Verfahren zur Überprüfung und/ oder Transformation eines Computerprogramms (10), das in einer Programmiersprache vorliegt, welche Funktionen erster Klasse unterstützt, bei dem eine Typüberprüfung (12) des Programms (10) oder zumindest eines Teils des Programms (10) durchgeführt wird, um jedem Ausdruck des Programms (10) oder Teils des Programms (10) einen Typen zuzuordnen, der aus einem Grundtypen und einer Bindungszeit besteht, wobei die Menge der Grundtypen mindestens Basistypen zur Beschreibung einfacher Werte und einen Funktionstypen zur Beschreibung von Funktionen umfasst und die Menge der Bindungszeiten mindestens eine statische Bindungszeit und eine dynamische Bindungszeit umfasst und wobei bei der Typüberprüfung (12) ein Funktionstyp nur gemeinsam mit der statischen Bindungszeit akzeptiert wird.
Verfahren nach Anspruch 1 ,
dadurch g e k e n n z e i c h n e t, dass
eine Fehlermeldung ausgegeben wird, wenn bei der Typüberprüfung (12) festgestellt wird, dass einem Ausdruck kein Typ zugeordnet werden kann.
Verfahren nach Anspruch 1 oder 2,
dadurch g e k e n n z e i c h n e t, dass
eine Fehlermeldung ausgegeben wird, wenn ein Ausdruck mit einem Funktionstypen als mögliches Ergebnis einer dynamischen Fallunterscheidung angegeben ist.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
eine Fehlermeldung ausgegeben wird, wenn bei der Typüberprüfung (12) festgestellt wird, dass in dem Programm (10) oder in dem Teil des Programms (10) ein Funktionstyp annotiert ist, der keine statische Bindungszeit aufweist.
5. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
auf den Bindungszeiten eine lineare Ordnung definiert ist, gemäß der die statische Bindungszeit kleiner ist als die dynamische Bindungszeit.
6. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
bei der Typüberprüfung (12) ein Typ mit einem Funktionstyp als Grundtyp nur dann als wohlgeformt angenommen wird, wenn der Funktionstyp einen wohlgeformten Zieltyp der Funktion und für die ein oder mehreren Variablen der Funktion jeweils einen wohlgeformten Definitionstyp angibt und wenn der Typ eine statische Bindungszeit aufweist.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
die Menge der Grundtypen eine Menge von zusammengesetzten Grundtypen zur Beschreibung von zusammengesetzten Werten um- fasst, die zumindest einen Paartypen zur Beschreibung von Paaren von Werten umfasst, wobei bei der Typüberprüfung (12) ein Typ mit einem Paartyp als Grundtyp vorzugsweise nur dann als wohlgeformt angenommen wird, wenn die Typen, welche die Elemente des Paares beschreiben, jeweils wohlgeformt sind und Bindungszeiten aufweisen, die nicht kleiner sind als die Bindungszeit des Typen mit dem Paartyp als Grundtyp.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch g e k e n n z e i c h n e t, dass
bei der Typüberprüfung (12) einem Ausdruck, der eine Funktion mit zumindest einer Funktionsvariablen definiert und eine Angabe des Typen jeder Funktionsvariablen sowie eine Angabe des Rumpfs der Funktion umfasst, genau dann, wenn der angegebene Typ jeder Funktionsvariable wohlgeformt ist und dem Rumpf der Funktion in dem Kontext, der den Kontext des Ausdrucks und die ein oder mehreren Funktionsvariablen mit jeweils den angegebenen Typen jeder Funktionsvariablen umfasst, ein Typ zugeordnet wird, ein Funktionstyp mit statischer Bindungszeit zugeordnet wird, welcher die für die eine oder mehreren Funktionsvariablen angegebenen Typen als Definitionstypen der Funktion und den dem Rumpf zugeordneten Typen als Zieltypen der Funktion angibt.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch g e k e n n z e i c h n e t, dass
bei der Typüberprüfung (12) einem Ausdruck, der ein Paar definiert, wobei ein erstes Element des Paares durch einen ersten Unterausdruck und ein zweites Element des Paares durch einen zweiten Unterausdruck angegeben ist, genau dann, wenn dem ersten Unterausdruck ein erster Typ und dem zweiten Unterausdruck ein zweiter Typ zugeordnet wird, ein Paartyp mit statischer Bindungszeit zuge- ordnet wird, der das erste Element des Paares durch den ersten Typen und das zweite Element des Paares durch den zweiten Typen beschreibt.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
sowohl auf der Menge der Typen als auch auf der Menge der Grundtypen jeweils eine reflexive und transitive Subtypbeziehung definiert ist, insbesondere wobei ein erster Typ genau dann als Subtyp eines zweiten Typen angenommen wird, wenn die Bindungszeit des ersten Typen kleiner oder gleich der Bindungszeit des zweiten Typen ist und wenn der Grundtyp des ersten Typen ein Subtyp des Grundtypen des zweiten Typen ist.
Verfahren nach Anspruch 10,
dadurch gekennzeichnet, dass
ein erster Funktionstyp genau dann als Subtyp eines zweiten Funktionstypen angenommen wird, wenn jeder Definitionstyp des zweiten Funktionstypen ein Subtyp des jeweiligen korrespondierenden Definitionstypen des ersten Funktionstypen ist und der Zieltyp des ersten Funktionstypen ein Subtyp des Zieltypen des zweiten Funktionstypen ist.
Verfahren nach Anspruch 10 oder 11,
dadurch gekennzeichnet, dass
ein erster Paartyp genau dann als Subtyp eines zweiten Paartypen angenommen wird, wenn der Typ des ersten Elements des ersten Paartypen ein Subtyp des Typen des ersten Elements des zweiten Paartypen ist und der Typ des zweiten Elements des ersten Paarty- pen ein Subtyp des Typen des zweiten Elements des zweiten Paartypen ist.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch g e k e n n z e i c h n e t, dass
bei der Typüberprüfung (12) einem bedingten Ausdruck, dessen Bedingung durch einen ersten Unterausdruck angegeben ist und dessen wenigstens zwei Fälle durch einen zweiten und einen dritten Unterausdruck angegeben sind, genau dann, wenn dem ersten Unterausdruck ein erster Typ mit einem Bool'schen Grundtyp und einer beliebigen ersten Bindungszeit zugeordnet wird und wenn dem zweiten und dritten Unterausdruck jeweils ein identischer zweiter Typ mit einem beliebigen Grundtypen und der ersten Bindungszeit zugeordnet wird, der zweite Typ zugeordnet wird.
Verfahren zur Transformation eines Computerprogramms (10), das in einer Programmiersprache vorliegt, welche Funktionen erster Klasse unterstützt, bei dem eine Typüberprüfung (12) des Programms (10) oder zumindest eines Teils des Programms (10) durchgeführt wird, um jedem Ausdruck des Programms (10) oder Teils des Programms (10) einen Typen zuzuordnen, der aus einem Grundtypen und einer Bindungszeit besteht, wobei die Menge der Grundtypen mindestens Basistypen zur Beschreibung einfacher Werte und einen Funktionstypen zur Beschreibung von Funktionen umfasst und die Menge der Bindungszeiten mindestens eine statische Bindungszeit und eine dynamische Bindungszeit umfasst,
wobei bei der Typüberprüfung (12) ein Funktionstyp nur gemeinsam mit der statischen Bindungszeit akzeptiert wird, und
wobei, wenn das Programm (10) oder der Teil des Programms (10) von der Typüberprüfung (12) akzeptiert wird, durch partielle Aus- wertung des Programms (10) oder des Teils des Programms (10) alle in dem Programm (10) oder dem Teil des Programms (10) enthaltenen Funktionen erster Klasse eliminiert werden.
Verfahren nach Anspruch 14,
dadurch gekennzeichnet, dass
das partiell ausgewertete Programm in einen Maschinencode (20) für eine Hardwareplattform übersetzt wird, die keine Unterstützung für Funktionszeiger bietet und/ oder keine Unterstützung für eine dynamische Speicherverwaltung bietet.
PCT/EP2014/055751 2013-04-03 2014-03-21 Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse WO2014161731A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/782,169 US10048951B2 (en) 2013-04-03 2014-03-21 Method for type checking and transformation of a computer program with first-class static functions
EP14711534.9A EP2965199A1 (de) 2013-04-03 2014-03-21 Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP13162073.4 2013-04-03
EP13162073.4A EP2787437A1 (de) 2013-04-03 2013-04-03 Verfahren zur Überprüfung und/oder Transformation eines Computerprogramms mit statischen Funktionen erster Klasse

Publications (1)

Publication Number Publication Date
WO2014161731A1 true WO2014161731A1 (de) 2014-10-09

Family

ID=48050483

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/055751 WO2014161731A1 (de) 2013-04-03 2014-03-21 Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse

Country Status (3)

Country Link
US (1) US10048951B2 (de)
EP (2) EP2787437A1 (de)
WO (1) WO2014161731A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9329849B2 (en) * 2013-08-26 2016-05-03 Facebook, Inc. Systems and methods for converting typed code
US10089089B2 (en) * 2015-06-03 2018-10-02 The Mathworks, Inc. Data type reassignment
US10261763B2 (en) * 2016-12-13 2019-04-16 Palantir Technologies Inc. Extensible data transformation authoring and validation system
CN109783175B (zh) * 2019-01-16 2023-03-31 平安普惠企业管理有限公司 应用程序图标管理方法、装置、可读存储介质及终端设备
CN110399131A (zh) * 2019-05-23 2019-11-01 中国平安财产保险股份有限公司 提高应用程序稳定性的方法、装置、计算机设备

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3178151B2 (ja) * 1993-03-19 2001-06-18 富士ゼロックス株式会社 オブジェクト指向言語のメッセージコンパイル装置
US5742828A (en) * 1994-08-03 1998-04-21 Microsoft Corporation Compiler and method for evaluation of foreign syntax expressions in source code
US7036111B2 (en) * 2001-06-01 2006-04-25 Hewlett-Packard Development Company, L.P. Code verification system and method
US7146604B2 (en) * 2003-01-06 2006-12-05 Xerox Corporation Program operators for composing abstractions
US7389498B2 (en) * 2003-03-25 2008-06-17 Microsoft Corporation Core object-oriented type system for semi-structured data
TWI320913B (en) * 2006-08-30 2010-02-21 Via Tech Inc Methods, systems and computer-readable storage medium for shading process compiling of 3d computer graphics
US8813043B2 (en) * 2008-12-31 2014-08-19 Microsoft Corporation Unifying type checking and property checking for low level programs
US9075667B2 (en) * 2009-05-21 2015-07-07 Microsoft Technology Licensing, Llc Dynamic binding directed by static types
US9009684B2 (en) * 2012-04-18 2015-04-14 International Business Machines Corporation Method, apparatus and product for porting applications to embedded platforms

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"TAPSOFT '97: Theory and Practice of Software Development", vol. 1214, January 1997, SPRINGER-VERLAG, Berlin/Heidelberg, ISBN: 978-3-54-062781-4, article PETER THIEMANN: "A unified framework for binding-time analysis", pages: 742 - 756, XP055076900, DOI: 10.1007/BFb0030638 *
DIRK DUSSART ET AL: "Polymorphic recursion and subtype qualifications: Polymorphic binding-time analysis in polynomial time", 25 September 1995, STATIC ANALYSIS, SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 118 - 135, ISBN: 978-3-540-60360-3, XP019179076 *
GUSTAVO ARROYO ET AL: "A Transformational Approach to Polyvariant BTA of Higher-Order Functional Programs", 17 July 2008, LOGIC-BASED PROGRAM SYNTHESIS AND TRANSFORMATION, SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 40 - 54, ISBN: 978-3-642-00514-5, XP019115207 *
MONNIER S ET AL: "Inlining as staged computation", JOURNAL OF FUNCTIONAL PROGRAMMING, vol. 13, no. 3, May 2003 (2003-05-01), pages 647 - 676, XP009172119, ISSN: 0956-7968, [retrieved on 20030513], DOI: 10.1017/S0956796802004616 *
NEIL MITCHELL ET AL: "Losing functions without gaining data", PROCEEDINGS OF THE 2ND ACM SIGPLAN SYMPOSIUM ON HASKELL, HASKELL '09, January 2009 (2009-01-01), New York, New York, USA, pages 13 - 24, XP055076895, ISBN: 978-1-60-558508-6, DOI: 10.1145/1596638.1596641 *

Also Published As

Publication number Publication date
US20160124727A1 (en) 2016-05-05
EP2787437A1 (de) 2014-10-08
US10048951B2 (en) 2018-08-14
EP2965199A1 (de) 2016-01-13

Similar Documents

Publication Publication Date Title
WO2014161731A1 (de) Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse
DE69924857T2 (de) Programm-kode-umwandlung
EP0674784B1 (de) Verfahren zum testen mindestens einer klasse eines objektorientierten programmes auf einem rechner
US8423971B2 (en) Generating an application software library
DE602004006253T2 (de) Vorrichtungen und verfahren zur wiederherstellung der synchronisation für objektorientierte softwareanwendungen in verwalteten laufzeitumgebungen
DE19945992A1 (de) Dynamisch optimierender Objektcode-Übersetzer zur Architekturemulation und dynamisches optimierendes Objektcode-Übersetzungsverfahren
EP3032408B1 (de) Verfahren zur erzeugung von lauffähigen applikationen mit dynamischen skalierbaren vektorgrafiken
DE112011103406T5 (de) Verwaltung von nicht geänderten Objekten
DE102005040075A1 (de) Dynamisches Verbinden von Modulen in einer Vorbetriebssystemumgebung
DE112011103428T5 (de) Automatisierte Analyse zusammengesetzter Anwendungen
DE202014010926U1 (de) Ein System zur Modellierung von Quellcode mit Codesegmenten, denen der Quellort fehlt
DE102004009676A1 (de) Verfahren und Systeme zum Erzeugen von Unterstützungsdateien für Befehle
Bodden et al. Avoiding infinite recursion with stratified aspects
DE102004017050A1 (de) Datenkonsistenz in Datenverarbeitungsanlagen
EP1622022A1 (de) Automatische Erzeugung von Testfällen
WO2009010338A1 (de) Verfahren zur rechnergestützten obfuskierung eines softwareprogramms und computerprogrammprodukt
Inostroza et al. Modular interpreters for the masses: Implicit context propagation using object algebras
DE102019105418B3 (de) Verfahren zum Erzeugen einer Darstellung einer Programmlogik, Dekompiliervorrichtung, Rekompiliersystem und Computerprogrammprodukte
DE112011103505T5 (de) Verfahren zum Validieren von Laufzeitreferenzen
EP1609061A2 (de) Verfahren und anordnung zur veränderung von software oder quellcode
DE60213786T2 (de) System und verfahren zur automatischen erfassung von aussagen in einer java-kompatibilitätsprüfumgebung
EP0662226B1 (de) Verfahren zur bearbeitung eines anwenderprogramms auf einem parallelrechnersystem
DE102005002362A1 (de) Programmsystem sowie Verfahren und Systemanordnung zu seiner Konfiguration
DE102020118832B3 (de) Verfahren zum Bereitstellen sicherheitsrelevanter Daten mittels eines Serversystems, Serversystem und Computerprogrammprodukt
Figueroa et al. Compositional reasoning about aspect interference

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14711534

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2014711534

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2014711534

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14782169

Country of ref document: US