EP2965199A1 - 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

Info

Publication number
EP2965199A1
EP2965199A1 EP14711534.9A EP14711534A EP2965199A1 EP 2965199 A1 EP2965199 A1 EP 2965199A1 EP 14711534 A EP14711534 A EP 14711534A EP 2965199 A1 EP2965199 A1 EP 2965199A1
Authority
EP
European Patent Office
Prior art keywords
type
function
program
expression
binding time
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP14711534.9A
Other languages
English (en)
French (fr)
Inventor
Kai Trojahner
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dassault Systemes 3DExcite GmbH
Original Assignee
Dassault Systemes 3DExcite GmbH
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 Dassault Systemes 3DExcite GmbH filed Critical Dassault Systemes 3DExcite GmbH
Priority to EP14711534.9A priority Critical patent/EP2965199A1/de
Publication of EP2965199A1 publication Critical patent/EP2965199A1/de
Withdrawn legal-status Critical Current

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.
  • shader programs are responsible for the display of shades on the surfaces to be displayed, in particular three-dimensional geometric objects, the representation depending on a respectively assumed light incidence and surface material.
  • These shader programs can be very complex and are executed many times as part of a rendering process, and are thus typically critical to the rendering time of the graphics software.
  • the development of new shader programs or "shaders" from scratch for every possible combination and design of rendering procedures and hardware platforms is associated with a high economic outlay. Therefore, it is desirable to design shader programs in a shader programming language that, unlike hardware platform-specific programming languages, is not tied to a particular hardware.
  • a first-class function also referred to as a first-class function
  • first-class functions may be passed as an argument to a higher order function, provided as a return value by a higher order function, assigned to a variable as a value, or used as an element in a data structure
  • the object of the invention is to specify a method which makes it possible to check computer programs with functions of the first class to determine whether the respective program can be transformed into an equivalent program which is identical in terms of its functionality and which does not have any functions of a higher order .
  • the check should be feasible with little expenditure of time and possibly enable a precise specification of the program component, as a result of which the program can not be transformed.
  • a transformable program should be transformed accordingly and then, if necessary after translation into a corresponding machine code, be executed on the respective 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 apply function is a higher order function.
  • the apply function takes a function f as an argument that maps two integers to another integer, as indicated in the program code by the annotated function type "(int, int) -> int".
  • the apply function applies f to the two other integer arguments a, b and returns the result.
  • the foo function uses the apply function to either add or subtract two integer values, depending on the value of the Boolean argument p.
  • program code 1 can be transformed by partial evaluation at compile time into an equivalent program of first order, ie without functions of first class.
  • program code 2 the calls of the function apply are respectively replaced by the body of the function apply, so that the functions add and sub, which are first order, are called directly. Replacing the function calls is also known as inlining or expanding.
  • Program code 2 int add (int a, int b) ⁇ return a + b; ⁇
  • Program code 3 int foo (bool p, int a
  • the program code 3 declares an identifier f representing a function, either the function add or the function sub, depending on the value of the boolean argument p of the function foo.
  • f a, b
  • the definition of the function apply can be formally used by the compiler by inlining, so that the call of the function apply in the program code 3 takes the form f (a, b). Since the Value of f but depends on the value of the variable p, neither add nor sub can be directly applied if the value of p is not statically known, which is the case, for example, when the function foo is a so-called Entry function of a program at which program execution begins.
  • the above program codes 1 to 3 illustrate that certain programs with first-class functions can be transformed by partial evaluation into first-order equivalent programs, ie programs without first-class functions, and not other programs. Only if functions in the program are statically known can the program be transformed by partial evaluation into a first-order program.
  • the method determines whether the program can be transformed by partial evaluation into a first-order program, ie without functions of the first class.
  • Example 1 For the program code 1, this is concretely illustrated in the "Example 1" which follows the general description below and which describes in detail a checking method performed on this concrete program. Since the checking and classification according to the invention is based on a type check, this can be done without evaluation of the program.
  • Type checks are known per se and are based on a language-specific set of typing rules, which together define a type system and which classify the expressions of a program according to the type of values that they calculate. NEN. The typeability of all expressions of a program or part of a program by successful application of the typing rules determines whether the program or the program part is permissible or not.
  • the invention extends the known type of validation to assigning to each expression both a primitive describing the value of the expression and a binding time describing the time of evaluation of the expression.
  • the type system is specially designed for a two-stage evaluation of the program, which includes a static, ie at compile time, partial evaluation of the program and a subsequent dynamic, ie at runtime, remaining evaluation of the program.
  • the type system differentiates according to expressions with static binding time, ie expressions that can be partially evaluated at compile time, on the one hand, and expressions with dynamic binding time, ie expressions that can only be evaluated at runtime, and on the other hand selectively allows the formulation of programs which can be converted by the static partial evaluation into programs without functions of first class.
  • the combined typing according to basic types and binding times makes it possible to determine in a particularly simple manner and without prior evaluation of the entire computer program whether the program can be transformed into an equivalent first-order program or not. It can be ensured with little effort that at least all those programs are rejected that contain first-class functions and in which the described transformation is not possible.
  • each expression is checked for itself on the basis of the typing rules, so that when a type error occurs in the program, it can be determined at which point of the program the error has occurred.
  • an exact indication of the "erroneous" or illegal program component and a corresponding error message to the user is possible, whereby the troubleshooting for the programmer is greatly facilitated.
  • the method allows a programmer to more easily program a program, such as a shader program, using first class functions, which can be transformed into a first order equivalent program.
  • first class functions which can be transformed into a first order equivalent program.
  • static functions of the first class which are also referred to as static first class funetions
  • dynamic functions of the first class are not accepted.
  • the targeted and specific permitting of static first class funetions enables the modular development of programs, which can all be transformed into first-order programs, which can be executed in a shorter runtime independently of the hardware platform executing the software. This ensures a higher net performance of the computer, for example when rendering 3D visualizations.
  • Type checking is used to assign a type to each expression of the program using given typing rules.
  • the type checking may include applying a plurality of typing rules defining a type system, wherein different rules are provided for different types of expressions.
  • the typing rules assign types to the expressions of the program, which consist of the basic type and the binding time of the respective expression.
  • a basic type eg a function type or basic types
  • “with” a static or dynamic binding time or a “static” or “dynamic” basic type this refers to a type having the respective basic type and the respective binding time.
  • a type "with” a basic type eg, "with” a function type
  • the typing rules of the type system preferably include type mapping rules that indicate under what conditions a particular type of expression is associated with a particular type of expression. Further, the rules preferably include well-formedness rules which indicate under which conditions a type is assumed to be well-formed and may be used accordingly.
  • sub-typing rules can be provided which specify the conditions under which a particular type is assumed to be a subtype of another type.
  • type systems are known per se and described, for example, in "Types and Programming Languages" by Benjamin C. Pierce, MIT Press, 2002.
  • an error message is output if it is determined during the type check that a type can not be assigned to an expression. This is the case in particular when a typing or printing method to be applied to the respective printout is used
  • Type assignment rule can not be applied successfully because the expression does not meet the requirements set by the typing rules.
  • the error message indicates the expression or subexpression that can not be typed. In this way, the error and also the exact cause or location in the program code which causes the error can be communicated to a programmer, so that the error can be easily corrected by appropriate modification of the program code.
  • an error message is output if an expression with a function type is specified as a possible result of a dynamic case distinction.
  • a case distinction comprises a condition on which the result of the case distinction depends, and consists, for example, of an if-else expression.
  • 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.
  • An expression having a function type in the above-described embodiment is preferably also an expression having a basic type composed of one or more types, wherein at least one of the types constituting the basic type has a function type as a basic type having. Such a type is also referred to herein as a "containing" type of function.
  • Basic composite types are explained in more detail below.
  • EBNF Backus-Naur-Form
  • the set of basic types C comprises base types B, which are not given in the above table.
  • the base types B describe simple values and can include at least one base type each for integer numerical values (base type: "int") and Boolean values (base type: "bool").
  • the set of basic types C also includes function types Ti-> T2 and pair types Ti XT2, where a function type Ti-> T2 describes a function that calls an argument of type Ti (also called definition type) on a value of type T2 (also called target type). and where a pair type Ti XT2 describes a pair of values each having a value of Ti or T2.
  • Basic types C that specify one or more types Ti, T2, ie the function type Ti-> T2 and the pair type Ti XT2 in Table 1, are also referred to below as composite basic types.
  • Types having a basic compound type as the basic type are accordingly referred to as composite types.
  • the Symbol sequence x: T defines the variable x as a variable of the function for which the type T has been explicitly annotated as a type by the user, for example.
  • the symbol e symbolizes the body of the function.
  • the expression syntax further includes applications ei2 representing the application of a function ei to an argument e2, pair constructors
  • the set of values v comprises the constant symbols c, functions or abstractions ⁇ : ⁇ . ⁇ and pairs of values (v, v).
  • a type-checking context ⁇ which is also referred to simply as a context, is a list of pairs that associate one type each with the variable x of the program.
  • the symbol sequence x: T means that the variable x has been assigned the type T.
  • ⁇ A point refers to the empty context.
  • a program preferably represents exactly one expression in the programming language used, which in particular uses a ⁇ syntax or can be represented in it.
  • An expression typically consists of several subexpressions, which in turn can contain expressions. Applying the type mapping rules to an expression requires that the subexpressions be recursively typed first until the entire expression is typed or type checking results in a type error.
  • an error message is output if it is found during the type check that a function type Ti-> T2 is annotated in the program or in the part of the program which has no static binding time S.
  • the type annotation may e.g. of the type x: T and serves to define the type T of a function variable x in a function definition ⁇ : ⁇ . ⁇ .
  • the Typannota- tion is preferably made manually by the programmer in the formulation of the program. The above measure ensures that in such type annotations only permissible types of functions, i. Function types with static education time, to be accepted.
  • An explicit type annotation makes it possible to check an expression that defines a function, irrespective of the other expressions of the program and, in particular, independently of an operand to which the function is possibly applied, on its type and its admissibility. For this purpose, it is checked whether the annotated type of the function variable itself is permissible and whether the body of the function is allowed for the function variable, assuming the annotated type. It is a principal advantage of the method described herein that individual terms or program parts can be independently checked for their types, irrespective of the other terms or program parts. without having to have all other parts of the program and thus the entire program at the same time. Instead, it is for
  • Type checking an expression in any case sufficient, if Time of review only the types of other terms or program parts are known. This allows for modular programming and review, which greatly facilitates the creation of legitimate programs.
  • the above-described rule for verifying type annotations in the case of function definitions may be realized by a corresponding type assignment rule to be applied to function definitions, possibly in combination with a well-formed rule indicating under what condition a type having a function type as a basic type is supposed to be well-formed becomes.
  • a corresponding type assignment rule T-LAM is given by way of example, which includes the assumption that for a term ⁇ : ⁇ . ⁇ the type T is well-formed (expressed by T: *) and a well-formedness rule WF-FUN, in which the Prerequisite is that a function type is well-formed only with static binding time.
  • 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.
  • explicit type annotation in the definition of function variables facilitates type checking and allows modular verification and meaningful fault diagnosis.
  • the method may therefore require that in function definitions an explicit annotation of the type as described above be provided for each function variable, whereby otherwise, for example, an error message may be output.
  • an explicit annotation of the type as described above be provided for each function variable, whereby otherwise, for example, an error message may be output.
  • the annotation of a complete type with both basic types and binding time of the respective function variable is required.
  • a function definition includes an explicit type annotation, but which specifies only the basic type and not the binding time of the type of variable and / or if the annotation specifies a composite basic type for the function variable indicates the basic type of the types that make up the compound base type, ie x: (int- ⁇ int) instead of x: S (Dint-> Dint).
  • the method can then treat the definition as if a permissible standard type had been annotated which basic types and a binding time allowed for this basic type. For example, the static binding time for functions and / or - if permitted - the dynamic binding time for all other types can be assumed. Alternatively, an error message can be issued and / or a request can be issued to annotate the binding time.
  • an explicit annotation of the binding time is required at least for function types.
  • a linear order is defined on the binding times M according to which the static binding time S is less than the dynamic binding time D.
  • type checking it can be allowed that an expression with a static binding time S can also be used at a position in the program where an expression with a dynamic binding time D is expected, provided a corresponding well-formed expression Type with a dynamic binding time exists.
  • expressions with a static base type can also be used if a dynamic base type is expected, while on the other hand, function expressions can only be used with static binding time because there is no well-formed function type with dynamic binding time.
  • Such order may be determined by a rule such as e.g.
  • the following rule will be formalized B-STATIC, the applicability of which will be checked if in a type assignment rule a certain order of the
  • Binding times of sub-expressions of a typed expression is specified as a prerequisite.
  • the order of the binding times is preferably reflexive, as formalized below by the exemplary rule B-REFL: S ⁇ : D (B - STATIC)
  • a basic type B with each binding time S, D is preferably assumed to be well-formed. It is thus possible to use variables in the program which contain dynamic values of the respective base type, e.g. integer dynamic numerical values or dynamic floating point numerical values, as well as variables representing statically known values of the respective base type.
  • the assumption of basic types with each binding time as well-formed is preferably specified in a well-formedness rule for base types.
  • a corresponding exemplary rule WF-BASE is given below:
  • a type M (Ti-> T2) having a function type Ti-> T2 as the basic type is assumed to be well-formed only if the function type is a well-formed target type T2 and for the one or more variables of the function one each well-defined definition type Ti, and if the type M (Ti-> T2) has a static binding time S.
  • the condition described above can be realized by a well-formedness rule used to determine whether a function type is well-formed.
  • This well-formedness rule may correspond in particular to the WF-FUN rule mentioned above.
  • the above rule WF-FUN is applicable to unary or single-digit functions, ie functions whose definition set comprises exactly one variable. In principle, it is also possible for multi-digit functions, ie
  • Multi-variable functions set up a rule that checks whether each type of definition is a well-formed type and whether the target type is well-formed to take a feature type as well-formed.
  • a multi-digit function can always be represented as a nesting of a corresponding number of unary functions, for the sake of simplicity, the functions that are specifically formulated as examples in this case are based on unary functions.
  • the well-formedness rules are preferably used whenever a type is annotated in a function definition whose well-formedness is to be checked, and preferably when an expression is to be assigned a supertype in the context of a subtyping, so that the expression meets the requirements of can meet applicable type assignment rule, as further explained below.
  • the set of basic types C comprises a set of composite basic types for describing composite values comprising at least one pair type Ti XT2 for describing pairs of values.
  • Such compound basic types for describing composite values, and in particular pair types allow the merging of multiple values into pairs, and by nesting multiple pairs into each other, the composition of any number of values is possible, thereby greatly increasing the flexibility of programming.
  • a basic type for describing a composite value preferably indicates a basic type for each of the elements or each of which the composite value is composed.
  • a type M (Mi Ci> ⁇ M2 C2) having a pair type M1 C1 XM2 C2 as the basic type is assumed to be well-formed only when the types M1 C1, M2 C2 describing the elements of the pair each are well-formed and have binding times Mi, M2 that are not smaller than the binding time M of the type
  • the well-formedness of a couple type as described above is preferably checked by applying a well-formedness rule for pairs, which may correspond, for example, to the following WF-PAIR rule:
  • an expression ⁇ : ⁇ . ⁇ defining a function with at least one function variable x and an indication of the type T of each function variable x and an indication of the body e of the function if and only if specified Type T of each function variable x is well-formed and includes the body e of the function in the context that includes the context ⁇ of the expression ⁇ : ⁇ . ⁇ and the one or more function variables x with the respectively specified type T of each function variable x Type T is assigned a function type T-> T with static binding time S, which specifies the type T specified for the one or more function variables x as definition types of the function and the type T associated with the body e as the target types of the function.
  • each function variable x is preferably an explicit type annotation as described above, for example by the programmer.
  • function definitions are typed and thus initially allowed, so that the programming of static functions of the first class is made possible.
  • functions are only used in such a way that they can be statically evaluated, otherwise a typing error occurs and a corresponding error message can be output.
  • the conditional expression typing rule to be described it is ensured that the use of a function definition as a branch or case in a conditional if else expression that has a condition with a dynamic binding time results in a type error.
  • the conditional expression in this case could not be eliminated by partial evaluation and thus the program could not be partially evaluated into a first order program.
  • the rule described above is realized by a type-assignment rule that is applied when typing a function definition.
  • An exemplary rule T-LAM for unary function definitions is given below. T: * ⁇ , ⁇ : ⁇ he: ⁇ '
  • T means that the expression e in the context ⁇ of the expression is assigned the type T consisting of the base type and the binding time.
  • the typing context ⁇ of an expression e preferably contains at least those variables with the respectively assigned types which are defined in the terms above the respective expression, wherein in the type assignment rules given by way of example the symbol ⁇ always assigns the context of the respective type assignment rule typifying expression.
  • T-LAM accordingly says that the expression ⁇ : ⁇ . ⁇ in the context ⁇ of the expression ⁇ : ⁇ . ⁇ is assigned the specified type under the further conditions specified if the term e in the context ⁇ , x : T, ie the context containing the context ⁇ of the expression ⁇ : ⁇ . ⁇ itself as well as the additional type assignment pair x: T with the variable x and the type T assigned to type T.
  • the above rule is preferably realized by a type assignment rule which is checked when typing a phrase defining a pair.
  • a type assignment rule which is checked when typing a phrase defining a pair.
  • a reflexive and transitive subtype relationship is defined both on the set of types T and on the set of basic types C.
  • a subtype relationship determines under which conditions a type is a subtype of another type, the latter type being called a supertype. If a type is a subtype of a different type, type checking will allow an expression to which the subtype is assigned, preferably wherever an expression of the supertype is allowed or expected, provided both types are well-formed.
  • the definition of subtype relationships simplifies type checking because different types can be treated with the same typing rules. To check if one type is a subtype of another type, one or more subtype rules can be checked and applied that define when one type is a subtype of another type.
  • the binding time M of the first type T is less than or equal to the binding time M 'of the second type
  • the basic type C of the first type T is a subtype of the basic type C of the second type T.
  • the above subtype relationship ensures that a static expression can always be used in the program where the expression is expected to have a corresponding basic type and a dynamic binding time, provided that both types are well-formed.
  • the above rule is preferably realized by a subtype rule that is used to check if one type is a subtype of another type.
  • a rule SUB-TYPE is given below by way of example:
  • T means that the type T is a subtype of the supertype T. While the preceding rule defines subtype relationships between types consisting of binding time and basic type, subtype relationships between basic types are explained below.
  • 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.
  • the above rule is preferably implemented by a subtype rule for function types that is used to check if a function type is a subtype of another function type.
  • a rule SUB-FUN is exemplified below.
  • 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.
  • an expression e to which a first type T is assigned is assigned an arbitrary second type T if and only if the second type T is well-formed and if the first type T is a subtype of the second type T.
  • the definition of the subtype relationships thus makes it possible to assign another type to an expression to which a type is assigned, which is a supertype of the second type.
  • the requirement that the super-type T to be assigned must be a well-formed type ensures that a syntactically-existing supertype is not assigned if it is not well-formed, so that, for example, no type of function with a dynamic binding time can be assigned.
  • 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.
  • conditional expression type condition assumes that the subexpressions forming the cases or branches of the conditional have the same binding time as the subexpression defining the condition, and the subexpressions forming the cases both have the same types at the same time. In view of possibly defined subtype relationships, these assumptions are equivalent to the fact that the subexpressions forming the two cases have a common supertype which has the same binding time as the term forming the condition.
  • 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
  • conditional expression whose condition is specified by a first subexpression and whose at least two cases are indicated by a second and a third subexpression will not be accepted if the conditional expression is assigned a dynamic binding time and at least one of the two cases is a function type of the basic type or a composite primitive containing a function type.
  • a further embodiment provides that, during the type checking, an expression e2 which defines an application whose operator is formed by a first subexpression ei and whose one or more operands, which are also referred to as arguments, are each represented by a further subexpression e2 are formed, if and only if a function type T2-> T is assigned to the operator and if one or more operands are each assigned a type T2 which is identical to the corresponding definition type of the function type T2-> T or a subtype of the same is, the target type T of the function type T2-> T is assigned as a type.
  • 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:
  • the program preferably has a specially marked definition of an entry-level function in which the evaluation of the program begins with the final direct execution on a computer system.
  • the starter function preferably has one or more function variables that can accept values passed to the program when called by another program so that the program can generate runtime-dependent results.
  • the definition of the entry-level function is also checked to see if it has an acceptable type.
  • the entry-level function is preferably checked and the entry-level function accepted only if it does not define function variables that have a static binding time, ie that may be required in particular for the one or more variables of the entry-level function annotated a type with a dynamic binding time is.
  • the starter function may not define function variables that have a function type, since a function type is allowed only with static binding time, but the static binding time for the function variables of the starter function is preferably not allowed for the above reasons.
  • it is preferably checked and the entry function is only accepted if its body is assigned to a type which is not a function type or which, for example in the case of a composite type, does not contain a function type.
  • 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 partial evaluation may include applying the semantics of the programming language to the terms contained in the program, evaluating sub-expressions whose value is statically known.
  • the partial evaluation may e.g. include inline expansion of the body of a function from a function definition in an application expression invoking the function. Suitable methods for partial evaluation are known per se and described, for example, in "Partial evaluation and automatic program generation" by Neil Jones, Prentice Hall International 1993.
  • the original program may be translated into a partially evaluated program that is in a programming language that may correspond to the programming language of the original program and / or the higher and / or high-level programming language can be.
  • the partial evaluation can be performed by interpreting the original computer program.
  • 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 program is preferably a shader program for 3D visualization, which, if appropriate after the transformation, can be executed directly by a processor, in particular a graphics processor, in order to generate a three-dimensional graphic and preferably display it on a display unit the verification, transformation, compilation and / or assembly can be performed on a general-purpose processor.
  • the generation of the graphics can be done in particular in real time.
  • Tables 3a, b, c, d are given the typing rules underlying the type checking.
  • the rules in Table 3a determine the linear order of the binding times
  • the rules in Table 3b determine the well-formedness of types
  • the rules in Table 3c determine subtype relationships between different types and between different basic types
  • the rules in Table 3d determine the type mapping to the program expressions.
  • 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 definition of the function apply corresponds to the definition of the function apply in the program code 1 or program code 4, wherein in the program code 5, unlike the program code 1 for the variable f not only the function type as the basic type, but also the prescribed for function types static binding time is explicitly annotated.
  • the "main" function is identified by its name as an entry-level function.
  • the variables a, b in the apply, add, sub, and main functions have no explicit binding time annotation. However, the variables a and b must be assigned a dynamic binding time so that the program can be allowed because the entry-level function must not define any static function variables.
  • the following program code 6 indicates the program according to program code 5 in the notation of the ⁇ -calculus, wherein the dynamic binding times of the variables a, b are omitted as a simplification.
  • 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.
  • Type checking involves checking the rule T-COND for the conditional expression if true then add equal sub.
  • the terms add and sub are already a type with a static one by the rule T-VAR Binding time has been assigned. Since also the condition of the above conditional expression, ie the constant "true", according to the rule type (c) given in Table 4, is assigned the type Sbool and thus a static binding time, the condition of the rule T-COND is satisfied that the condition and the two cases of the conditional expression have the same binding time so that the rule is applied successfully and typing continues.
  • 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.
  • Program code 9 bar- ⁇ p D bool.
  • Xa D int.
  • the type check determines that the function definitions ⁇ : D int. X and ⁇ : D int. 0 - x respectively describe static functions that map a dynamic integer value to a dynamic integer value.
  • conditional if-else expression to be checked with the T-COND rule. Since the term p, which is the conditional expression condition, has been assigned a dynamic binding time and the T-COND rule requires that the condition and the conditional expression cases have the same binding time, the successful application of the T-COND take the following form:
  • 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:
  • the single figure described below shows a flowchart illustrating a method for checking and transforming a computer program according to an embodiment of the invention.
  • the round fields respectively indicate input and output variables of the method and the angular fields identify process steps carried out using the respective input variables or generating the respective output variables.
  • a program 10 is in a high level programming language that supports first class functions.
  • a type check of the program 10 is performed to associate each expression of the program with a type comprising a basic type and a binding time of the expression, wherein type-checking accepts a function type having only a static binding time.
  • the partial evaluation of the program follows. If the type check is unsuccessful, an error message 16 is generated and output, for example, to a user via a display device of the computer system performing the method, the error message indicating the cause of the error.
  • the partial evaluation 14 transforms the program into an equivalent first order program, ie without first class functions. Subsequently, the partially evaluated program which is still present at the high-level language is translated in a method step 18 by compiling and assembling into a target program 20 for a hardware on which the target program 20 is then preferably directly exported. leads.

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:
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:
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)
Ί ι <: Ί ι \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 )
Γ h e : (Ί x T2)
(T-PRJI)
Γ h f st e : Ti
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
^ [(ei . ex ) ] = (V letj , V le2} )
ex if Ve fej = (ei j e2)
fst VE [fei eise
VE |if ep then et eise ej = e if VE [ePl then 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)
Regelanwendungsdiagramm 1 (Teil 3/4) cd
<
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
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
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.
EP14711534.9A 2013-04-03 2014-03-21 Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse Withdrawn EP2965199A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
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 (3)

Application Number Priority Date Filing Date Title
EP13162073.4A EP2787437A1 (de) 2013-04-03 2013-04-03 Verfahren zur Überprüfung und/oder Transformation eines Computerprogramms mit statischen Funktionen erster Klasse
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
EP14711534.9A EP2965199A1 (de) 2013-04-03 2014-03-21 Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse

Publications (1)

Publication Number Publication Date
EP2965199A1 true EP2965199A1 (de) 2016-01-13

Family

ID=48050483

Family Applications (2)

Application Number Title Priority Date Filing Date
EP13162073.4A Withdrawn EP2787437A1 (de) 2013-04-03 2013-04-03 Verfahren zur Überprüfung und/oder Transformation eines Computerprogramms mit statischen Funktionen erster Klasse
EP14711534.9A Withdrawn EP2965199A1 (de) 2013-04-03 2014-03-21 Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP13162073.4A Withdrawn EP2787437A1 (de) 2013-04-03 2013-04-03 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 (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2014161731A1 *

Also Published As

Publication number Publication date
WO2014161731A1 (de) 2014-10-09
EP2787437A1 (de) 2014-10-08
US20160124727A1 (en) 2016-05-05
US10048951B2 (en) 2018-08-14

Similar Documents

Publication Publication Date Title
DE60001916T2 (de) Plattformunabhängige speicherabbild analysearchitektur zur programmfehlerbeseitigung
DE60011479T2 (de) Xml-roboter
EP2965199A1 (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
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
EP2977888B1 (de) Verfahren und System zur Speicherung und zur Versionsverwaltung von Computerprogrammen
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
Cornélio et al. Refactoring by transformation
EP1609061A2 (de) Verfahren und anordnung zur veränderung von software oder quellcode
DE112011103505T5 (de) Verfahren zum Validieren von Laufzeitreferenzen
EP3935489A1 (de) Verfahren zum erzeugen einer darstellung einer programmlogik, dekompiliervorrichtung, rekompiliersystem und computerprogrammprodukt
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

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20151005

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160510