JPH06266561A - Method and system for inspecting type of program - Google Patents

Abstract

(57) [Abstract] [Purpose] To provide a method for efficiently performing type checking in a strongly typed object-oriented programming language. [Configuration] A class definition 121 stored in a data management system 120 is stored in a compiler 10 in a computer system 10.
0, the object 131, the execution code 133 and the type checking program 135 are generated, and the object 131, the execution code 133 and the type checking program 135 are stored in the object management system 130. The execution unit 110 executes the type checking program 135 while referring to the object 131, performs the type checking, and outputs the execution result.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION The present invention relates to a method of type checking in a strongly typed object oriented programming language.

[0002]

2. Description of the Related Art From the standpoint of expression / description in a programming language, a "type" of a program is introduced as a restriction on the value that a specific expression appearing in the program can take.

The type of programming language that handles abstract data, such as the object-oriented programming language used in this specification, is not intended to inform the compiler of information for compilation (size of data storage area, etc.). , Integrity of function call and message sending,
That is, it is specified that the information is for checking the consistency of the program.

The operation of checking whether the operation executed in the program is applied to the data having the proper type is called "type checking". For type checking of object-oriented programming languages, see "Iwanami Course Software Science 17 Models and Expressions" (Akinori Yonezawa, Etsushiya Shibayama, Iwanami Shoten, 1992) pp. 44-61. For general type checking, see “Compiler
I "(AV Eiho, R. Cethy, J. D. Ullman, Written by Kenichi Harada, Science, 1990) pp.
417-470.

There are two types of type checking, static type checking and dynamic type checking. Of these, static type checking is executed when the program is compiled. The dynamic type check is a check for embedding a type checking code in a code obtained by compiling a source program and checking whether or not an operation is applied to data having an appropriate type at the time of execution.

A strongly typed programming language means that a program that has passed a compiler passes the type check defined by the language and is type-safe (the operation is applied to improper data). Nothing)
Is to guarantee that

Conventional static type checking (hereinafter, static type checking is called type checking) is realized as one routine inside the compiler. The type check is performed according to the syntax tree generated by the lexical / syntactic analysis unit. Conversely, type checking cannot be performed independently of the lexical / syntactic analysis unit.

FIG. 2 shows each phase in a conventional object-oriented programming language compiler. 200 is a compiler, and class definition 12
1 is read and the class object 131 with the method execution code 133 is generated. The read class definition 121 is converted into a syntax tree by the lexical / syntactic analysis unit 201.

In accordance with this syntax tree, the type checking unit 202 uses type inference (information about the implicit type given in the text of the program as a clue, and uses strict logic to determine the types of expressions that appear in the text. Decide),
Check your program for typographical errors. If there is no type error (the operation is applied to invalid data), the syntax tree is passed to the intermediate code generation unit 203, and the intermediate code is generated.

The intermediate code is subjected to optimization processing by the code optimizing unit 204 and becomes an execution code by the code generating unit 205. On the other hand, information on various classes (classes) analyzed in each phase of the compiler is generated as a class object and is output together with the method execution code 133 in which the execution code generated by the code generation unit 205 is an object. It

[0011]

The conventional mold inspection method as described above has a problem in the following cases.

The first is type checking of a method that refers to an undefined type.

Generally, all types appearing in a program subject to type checking must be defined. For this reason, before defining the method, there is a restriction on the definition order that all types referenced by the method must be defined prior to the definition of the class, or the type that is always referenced in a compilation unit such as a file is defined. Assuming that is defined, the method using type variables is taken.

However, generally in an object-oriented programming language, it is possible to compile without declaring types. Also, in order to provide a flexible object-oriented programming environment, it is desirable that class definitions are independent of each other, that is, it is not necessary to be aware of the definition order or compilation unit.

Therefore, even if the referenced type is undefined, a method of compiling for the time being and performing type checking when the referenced type is defined to check the consistency of the program is conceivable. .

FIG. 3 is an example of a type reference relationship. 310
Is a definition of the class type1 and has a definition 311 of a method m11 and a definition 313 of a method m12 that refer to the type type0. Similarly, 320 is the definition of the class type2, and the type typ
It has a definition 321 of m21 that does not refer to e0 and a definition 323 of a method m22 that refers to type0. 300 is class type0
Definition of method m01, definition 301 of method m01 and method m02
Has a definition 303. Here, it is assumed that type0 is undefined. At this time, the type checking of the methods 311, 313, and 323 cannot be performed. So, for the time being, compile these three methods without type checking, and
When the definition 300 of pe0 is made, type checking is performed. The problem here is that the lexical / syntactic analysis exactly the same as the lexical / syntactic analysis performed at the time of compiling the methods 311, 313, and 323 must be performed again at the time of type checking.

Another case where problems occur is type checking involving class updates (changing class definitions). This is a big problem especially in systems that handle persistent objects, such as object-oriented databases.

Description will be made with reference to FIG. Class type
Consider the case where the definition 300 of 0 is updated, and for this reason the definition of type type0 is also updated. To check whether this update is consistent, check the definition of class type0 300
Recompiling and referencing type type0 method 31
It is necessary to perform mold inspection of 1, 313 and 323.

In the conventional type checking method, the type checking of each method must be performed by lexical / syntactic analysis. In a system that manages many classes such as an object-oriented database, it is considered that the number of methods that are referenced is extremely large, and performing type checking from lexical / syntactic analysis for all of these methods is a considerable load.

A further problem arises with the reuse of methods, in particular with inheritance, which is a standard feature of object-oriented programming languages (one class inherits variables and methods of another class as is). There is type inspection.

At this time, the type of the variable used in the method and declared outside the method may change after being inherited. For this reason, the method must be type-checked at the inherited destination to see if the integrity of the program can be maintained.

FIG. 4 shows how a method is inherited. Reference numeral 400 denotes a definition of class type0, which declares a variable X of type00 type. 401 is a method m0 defined using a variable X declared outside this method.
Reference numeral 410 is a definition of class type1, and method 401 is inherited from class type0. In addition, it has method m10 and method m11. In the definition 410 of class type1, the variable X
Is declared as type type11. Therefore, method 4
01 must be type-checked to see if the program consistency can be maintained even if the variable X is of type type11. Similarly, 420 is the definition of class type2, and method 4
It inherits 01 and has a method m2. The variable X is of type t
It is declared as ype22, and method 401 is variable X
It is necessary to perform type checking with the type of as type22. It should be noted here that the type check of the method 401 in the definition 400 of the class type0 and the type check of the method 401 and the definition of the class type2 in the definition 410 of the class type1 42
The type check of the method 401 in 0 is exactly the same except that the type of the variable X is different. However, each type check must be performed from the lexical / syntactic analysis of method 401.

As the above three cases show, even if only type checking is required for already compiled methods, it must be done again from lexical / parsing. Moreover, there is a problem in that it is often necessary to define exactly the same method many times.

An object of the present invention is to efficiently perform type checking of a strongly typed object-oriented programming language, and more specifically, to make the type checking independent of the compiler phase, and to make the lexical / syntax during the type checking. It is to provide a method of type checking that does not perform analysis.

Another object of the present invention is to compile
It is an object of the present invention to provide a method for reducing the restrictions on the programmer of a strongly typed object-oriented programming language without having to declare type definitions and specify the order of compilation separately from class definitions.

[0026]

In view of the above conventional problems, according to the present invention, there is provided a compiler for compiling a class definition including a method definition and a variable declaration written in an object-oriented programming language. In the computer system described above, the compiler is based on the type information generation means for generating type information about the type of the class defined by the class definition, the first holding means for holding this type information, and the held type information. A type check program generating means for generating a type check program for performing a type check for each of the methods can be provided.

Further, the system, when second type holding means for holding the type checking program generated by the compiler and type information relating to the type to be referred to by the method are generated, the type checking corresponding to the method is performed. Execution means for extracting the program from the second holding means and executing it based on the information about the type can be provided.

[0028]

Since the type checking procedure based on the syntax tree is recorded in the type checking program, it is not necessary to perform the lexical / syntactic analysis in the subsequent type checking. Therefore, the efficiency of the mold inspection is improved when the repeated mold inspection is performed.

Since the type that is not determined inside the method is treated as a type variable, it is possible to flexibly deal with the type checking in various cases.

Since the compilation and the type checking can be performed independently, the restrictions imposed on the programmer by the type checking are relaxed.

[0031]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 shows the configuration of the present invention in a system that handles persistent objects. FIG. 5 shows FIG.
The flow of each phase of the compiler 100 in FIG.

In FIG. 1, reference numeral 10 is a computer system having an arithmetic unit and a storage device. 1 and 5,
Reference numeral 120 is a system capable of managing text data such as a file system and a database. Thirteen
0 is a system capable of managing objects such as an object-oriented database. Reference numeral 121 is a class definition, which defines the structure and procedure of the object. This corresponds to a program. Reference numeral 131 is a class object, which is a generator of an instance object of the class, and manages various information of the entire class. 133 is a method execution code, which is a procedure activated when an object receives a message. Reference numeral 135 denotes a type checking program, which corresponds to each method. 133 and 135 are also objects,
It is under the control of the class object 131.

In FIG. 1, the compiler 100 reads the class definition 121 and creates a class object 131. At this time, a type checking program is also generated in addition to the method execution code.

The generated class object 131 is 1
Each class object can be called by a class name (type name).
Since the class name and the type name are the same, it is possible to obtain the class object having the definition information of the type by the type name.

Reference numeral 110 denotes a type check program execution unit,
The type checking program 135 is executed, and the type checking of the method corresponding to 135 is performed. The type information required to execute the type checking program is obtained from the class object corresponding to the type name. If the type checking program cannot be executed correctly, it indicates that the corresponding method has a type error. At this time, the type check program execution unit 110 outputs the type error information 112. In this way, the type checking program execution unit can perform the type checking by executing the type checking program. Therefore, the method having the type checking program can perform the type checking as needed, and at that time, it is not necessary to perform the lexical / syntactic analysis of the class definition in which the method is defined.

The phases of the compiler in which the class object 131, the method execution code 133, and the type checking program 135 are generated will be described with reference to FIG.

The class definition 121 is first converted into a syntax tree by the lexical / syntactic analysis unit 101. This syntax tree is analyzed, and the type checking program generation unit 102 generates a type checking program using the correspondence between the grammar rules and the type inference rules. This portion corresponds to the type checking unit 203 of the conventional compiler 200 in FIG. However, the type checking unit 203 directly performs type inference according to the syntax tree. The type checking program generation unit 102 in FIG. 5 does not perform type inference itself, but outputs the type inference method as a type checking program.

The syntax tree further includes the intermediate code generator 10
3, the intermediate code is generated, and the code optimization unit 10
The optimization processing is performed in 4, and the code generation unit 105 forms the method execution code. Various information analyzed in the series of processes of the compiler is output by the object generation unit 106 as a class object.

Here, a class defining method and an object type, which are prerequisites for explaining the above-described embodiment in more detail, will be described. FIG. 6 is a conceptual diagram of object types. FIG. 7 shows an example of class definition.

In FIG. 6, the type of an object is characterized by the object's interface of what messages can be sent to that object. With such a type definition, the type check is a check of whether the message is sent to the object correctly, that is, whether the method is called correctly-the integrity of the program. 611, 61
Reference numeral 3 is a method specification, 611 is a method name m01 :, and the argument type is type2 and the return value type is type3. Similarly, 613 is the method name m02,
There is no argument, and the return type is type1. 611 and 613
When a method such as is defined in the class type0 to be exposed to the outside, the method specification 61
A set 610 of 1, 613 is called a feature of type type0. An object 600 is said to be of type type0 when it has the characteristics of type type0, that is, when it can send the message m01: or m02. On the contrary, if the object 600 is declared as type type0, the method specification 6 is added to the object 600.
Sending a message like 15 is a typo.

The definition of the type type0 described in FIG. 6 is the definition of the class type0 in FIG. In FIG. 7, bold letters are reserved words of programming languages. 001
The line declares that the name of this class is type0. Line 002 is from line 002 to line 012,
Indicates that the definition is for an instance object of class type0. Line 003 is the declaration of the variable that the instance object of class type0 has, and variable X is type type1.
Is. Line 004 indicates that the method defined in the subsequent lines can be invoked from outside the object, that is, is a method exposed to the outside of the object. Lines 005 to 009 are the definition of the method m01 :. Line 005 is the name of the method
m01 :, indicating that the type of the argument x1 is type2 and the type of the return value is type3. Line 006 is a declaration of a temporary work variable used in the method. Line 007 is an expression indicating that the message m2 is sent to x1, the result is used as an argument, and the message m1 is sent to X, and the result is assigned to x2. The line 008 is a sentence meaning that the message m2 is sent to x2 and the result is used as the return value of the method m01 :. Line 011 is the definition of method m02. It has no arguments and the return type is type1. However, the detailed program is omitted. Hereinafter, “...” In the class definition in the figure, the omission is represented.

The structure of the type checking program and the class object that provides information necessary for its execution will be described in detail with reference to FIG.

FIG. 8 is a block diagram of a class object. The class object 131 manages the type information defined by the class, which is necessary for executing the type checking program. 801 is a class definition. If a type error is found during type checking, the position of the error can be indicated on the class definition. This is useful for programmers to correct errors. Reference numeral 803 is a variable table. This variable shows the structure of the object,
Declared outside the method. Reference numeral 805 indicates a class object that refers to the type represented by the class object. A class that is affected when the class is updated. Reference numeral 807 is type hierarchy information. In object-oriented programming languages, types may be ordered by the inheritance function. This is called a type hierarchy. Type hierarchy is type
If an object that is T1 is always of type T2, then T1 ≤
It can be defined as T2. At this time, T1 is called a subtype of T2. 809 is a method table. Method information is managed.

FIG. 9 is a detailed block diagram of the variable table 803 in FIG. Using the variable name as a key, it manages what type the variable is declared as, and what line of the class definition is made. Therefore, the table has the items of the variable name 901, the type 903, and the line number 905.

FIG. 10 shows the method table 809 shown in FIG.
3 is a detailed configuration diagram of FIG. Method specification 1003 and method execution code 13 using method name 1001 as a key
3. The type check program 135 can be taken out. 1005 is type reference information in the method, which is expressed as a subset of the type reference information 805 in FIG. The type reference information at the method level is provided in addition to the type reference information between classes, in order to suppress the type checking at the time of class update as much as possible. With only the type reference information between classes, all methods defined in a class must be subject to type checking. Reference numeral 1007 is a pointer to a method execution code, and 1009 is a pointer to a type checking program.

Here, the structure of the type checking program is shown in FIG.
Will be described with reference to. FIG. 11 is a configuration diagram of the method type checking program 135. The type checking program includes a type variable declaration section 1110 and a type checking code section 1120.
In the type variable declaration part, the type of the external variable whose type cannot be determined inside the method is registered as a type variable by the type check program generation part. Therefore, the table is a table that refers to the type variable 1113 generated by the type checking program generation unit using the external variable name 1111 as a key.

The type check code section 1120 describes the type check procedure, and is realized by, for example, a type inference formula. Line number 1123 is the line number of the class definition of the grammar element for which the type inference expression was generated. This line number informs the programmer of the position of a type error when a type error is found in the type inference expression.

The process of generating the type checking program of FIG. 11 will be described with reference to the example of the type checking program corresponding to the method defined in the class definition of FIG. 7 and the class definition of FIG. In FIG. 12, 1200
Is a type checking program of the method m01: defined in lines 005 to 009 of the definition of the class type0 in FIG. 1210 is a type variable declaration part, and 1220 is a type check code part. The type checking program is generated based on the syntax analysis. This situation will be described for each line of the class definition in FIG. 7.

(1) Line 005 It is analyzed that the method m01: inputs the argument x1 of the type type2 and outputs it as an object of the type type3. This analysis result is registered in the symbol table (not shown) of the compiler. Similarly, (2) Line 006: Temporary variable x2 is analyzed to be of type type2 and registered in the symbol table.

(3) Line 007 This line can be decomposed into the following three expressions. (A) Send the message m2 to the argument x1. (B) Using the result of (a) as an argument, the message m is stored in variable X.
Send 1: (C) The result of (b) is substituted into the temporary variable x2.

The process of generating the type checking program for these three expressions will be described.

(A) Draw a symbol table and the argument x1 is of type type2
Turns out to be Therefore, type checking is
2 objects can send message m2,
As a result, it will be checked whether to output any object. If we express this as a type inference expression
type2 => m2: → t1. Since the type of the argument is declared inside the method, the type of the argument x1 remains type2 no matter how the outside of the method is changed. Therefore, it is expressed as the fixed value type2.
However, as a result of sending message m2 to an object of type type2, the type of the output object is class type2
It depends on the definition of. Therefore, the type cannot be determined, and the type variable is t1. This type inference expression and the line number 007 for recording that this type inference expression was generated from line 007 of the class definition are registered in the type check code section 1220 of the type check program.

(B) Since the variable X is a variable outside the method, its type cannot be determined inside the method. Therefore, the type of the variable X is expressed as a type variable t0 and registered in the type variable declaration unit 1210 as an external variable name X and a type variable t0. The type inference expression at this time is t0 => m1 :: t using the type t1 of the object resulting from sending the message m2 to the argument x1.
Expressed as 1 → t2. This means that an object of type t0 can send the message m1 :, its argument type is t1, and its output type is t2. This type inference expression together with the line number 007 in the class definition is used in the type check code part 1
Register 220.

(C) From the symbol table, the temporary variable x2 is of type type2
It can be seen that it is. Since the temporary variable is declared inside the method, its type is fixed. Therefore, the variable
As a result of sending the message m1: to X, the type t2 of the output object should be a subtype of type2. This is expressed as t2 ≦ type2 and registered in the type check code part 1220 together with the line number 007.

(4) The message m2 is sent to the temporary variable x2 which is the 008 line type 2 and the result is the output of the method m01 :. The type inference expression for the expression that sends the message m2 to the object of type type2 is already registered, so it can be omitted. The type check code part 1220 of this embodiment is omitted. Therefore, the message m in the object of type type2
As a result of sending 2, the type of the output object is t1. From the symbol table, the output type of method m01:
Since it is known that the type is type3, the type inference expression t1 ≦ type3 that the type t1 is a subtype of type3 is added to the type check code part 1220 with a line number 008.

(5) Line 009 It is understood that the definition of the method m01: is completed, and the method
The execution code of m01: and the type checking program 1200 are generated. In this way, a type checking program is generated for each method based on the syntax analysis and managed by the class object.

Next, FIG. 13 shows a processing procedure for compiling a class and performing type checking using a type checking program.
This will be described with reference to the flowchart of FIG. Compile the class,
In order to perform type checking, all types referenced by the compiled class must be defined. Therefore, the class definition defining the referencing type must already be compiled or compiled together. Here, the description will be given on the assumption that a plurality of classes that refer to each other are compiled together.

FIG. 13 is a flow chart showing the procedure for compiling a plurality of class definitions. In step 1310, each class definition is compiled. The compilation order (definition order) of each class definition is arbitrary. As one of the phases, there is compilation of each method definition defined in each class (step 1311). In step 1311, the method execution code is generated and the type checking program 135 is generated. At this point, the type checking program cannot run because there are uncompiled class definitions, that is, there are undefined types.

Each compiled class is subjected to inheritance processing (step 1302) and each class object is generated (step 1303). Since the class object manages the information of each type, step 13
When 03 ends, the type checking program 135 generated in step 1311 can be executed. Therefore, the type checking program is executed while referring to the class object to check the type of the method defined in each class (step 1304). The result of this type check is determined (step 1305), and if there is no type error, the process ends (step 1307). If there is a type error, error processing such as output of an error message is performed (step 13).
06) Finish.

An example of the method of executing the type checking of step 1304 of FIG. 13, that is, the method of executing the type checking program will be described with a focus on the type checking program 1200 of FIG. 12 described above. The type checking program 1200 uses the method m01:
It is generated from the definition of, type type1, type type2, type
Refers to type3. Therefore, in order to execute the type checking program of FIG. 12, class type1 and class typ
The definitions of e2 and class type3 need to be compiled. However, the definition of these classes is
It need not precede the definition of type0.

Class type1, class type2, class type3
The definition of is shown in FIG. 1401 is class type1, 1
403 is a definition of class type2, and 1405 is a definition of class type3. 002 line of definition 1405 of class type3 is class t
Indicates that the superclass of ype3 is class type2,
Class type3 inherits the properties of class type2.

The information on the types obtained as a result of compiling the definitions of the classes type1, type2, and type3 in FIG. 14 is the type name in FIG. 15 and the pair of specification 1510 of the method that the object of that type has as an interface, and the type hierarchy. This is information 1520. These are managed by class objects for each class (type), but they are summarized in one figure for convenience of explanation. In 1510 of FIG. 15, 1 in FIG.
From the class definition 401, the type name is type1, the method has m1: as an interface, the argument object is type2, and the output object type is type3.
A type is defined such that From the class definition 1403 in FIG. 14, the type name is type2, the method m2 is an interface, and the type of the output object is type3.
14 is defined in FIG.
From the class definition of, the type name is type3, it has methods m2 and m3 as interfaces, method m2 is inherited from type type2, and method m3 defines a type that outputs an object of type type2. To be done.

From the definition of these types, the message m is assigned to the objects of type type2 and type3.
It turns out that 2 can be sent, but message m3 can only be sent by objects of type type3. This means that you can use an object of type type3 where an object of type type2 can appear. But the opposite is not possible. At this time, type3 is a subtype of type2 and is expressed as 1520 in FIG.

Now, the procedure of executing the type checking program will be described with reference to the above-mentioned FIG. 11 based on the flowchart of FIG. Execution of the type checking program starts (step 160).
Then, the type is first assigned to the type variable of the type variable declaration unit 1110 (step 1603). The type to be assigned is
The variable indicated by the external variable name 1111 is the type declared when performing the type check. This information is passed from outside when the type checking program execution unit is started. When the type variable is substituted, the type inference expression 1121 of the type check code unit 1120 is executed (step 1611).

It is judged whether or not this execution is normally completed (step 1613), and if it is normally completed, the process proceeds to the next type inference expression. If an execution error occurs, the cause of the error is analyzed from the content of the execution error and recorded together with the line number in the class definition (step 1615). Step 1611, Step 1613 and Step 1615
Is repeated until all type inference expressions are executed (161
0). Step 1 after execution of all type inference expressions
It is checked whether the execution error recorded in 615 exists (step 1605). If there is no execution error, the information that there is no type error is returned and the process ends (step 1607). If there is an execution error, the information recorded in step 1615 is returned as pattern error information and the process ends (step 1609).

The method of executing the type checking program described in the flow chart of FIG. 16 will be specifically described by using an example. An example is
This is a process of executing the type checking program of FIG. 12 based on the variable type declaration in the definition of the class type0 of FIG. The class definition in Figure 7 has been compiled,
In line 003 of FIG. 7, the fact that the variable X is of type type1 is managed by the class object of class type0. See also Figure 1 for information about referenced types.
See 5. However, it is actually managed by the class object.

In the execution of the type check program in FIG. 12, first, the value of the type variable declared in the type variable declaration unit 1210 is determined using the external variable name. The type variable t0 is assigned the value type1 from the class object of the class type0 using the external variable name X.

Next, the type inference expressions of the type check code part 1220 are executed in the order of arrangement. Type inference expression type2 => m2: → t1
First looks up the method m2 invoked by the message m2 using the type name type2. It can be seen from 1510 in FIG. 15 that the type of type name type2 has a method m2 and the type of the output object is type3. Therefore, type3 is assigned to the type variable t1. Then type inference expression t0 => m
1 :: t1 → t2 is executed. Type1 for type variable t0, typ for t1
Since e3 is assigned, method m1: which uses the type name type1 and takes an object of type type3 as an argument.
Find out. Similarly, from 1510 in FIG. 15 to type variable t2 type
Substitute 3 Here, the specification of the method m1: of the type name type1 in 1510 of FIG. 15 is to take an object of the type type2 as an argument. However, from the type hierarchy of 1520 in FIG. 15, since the type type3 is a subtype of the type type2, it is not an error to take an object of the type type3 as an argument.

Next, the type inference expression t2 ≦ type2 is executed. Since type3 has been assigned to the type variable t2, 152 in FIG.
It can be executed correctly from 0. The type inference expression t1 ≦ type3 is also correct because type3 is assigned to the type variable t1.
Therefore, the type checking program of FIG. 12 can be executed without error in the class definition of FIG. That is, there is no type error in the definition of the method m01: of the class definition of FIG. 7, and the consistency of the program is guaranteed.

The type checking method of the present invention is also effective for checking whether the consistency of programs can be maintained by inheritance processing. Next, a method of type checking associated with inheritance processing will be described with reference to the flowchart of FIG. 17 and the example of class definition of FIG.

FIG. 18 shows the definition of class type4. 00
In line 2 we declare that class type0 is a superclass of class type4. Therefore, the class type4 inherits the method m01: etc. defined in the class type0.
As described above, the method m01: refers to the external variable X. In class type0, variable X is declared as type type1. As described above, under this declaration, the method m01: guarantees program consistency. However, in class type4, variable X is declared as type type2 (line 004 in FIG. 18). At this time, the method m0
It is necessary to check the consistency of the program of 1 :. By using a type checking program, you can check the integrity of this program without recompiling the method.
It can be carried out. However, the type check involved in the inheritance process described in the flowchart of FIG. 17 is based on the premise that a new class is defined and compiled while other classes are already compiled and managed as class objects. There is. When compiling multiple classes described in the flow chart of FIG. 13, the type checking involved in inheritance processing is
As with other type checks, after the inheritance process, step 1304 of FIG. 13 is performed.

The type checking program (FIG. 12) of the method m01: of the class type0 has already been generated. Using this type checking program, the consistency of the program of the method m01: inherited by the class type4, that is, the type checking is performed.

In FIG. 17, first, the type checking program (FIG. 12) of the inherited method m01: is obtained from the class object of class type0 (step 1701). From the type variable declaration part (1210 in FIG. 12) of the type checking program, it is checked whether the external variable is redeclared in the class type4 which is the inheritance destination. If it has not been redeclared, the inheritance process is performed as it is (step 1707). Class ty
In pe4, since the variable X is redeclared as the type type2, the type type2 is assigned to the type variable t0 of 1210 in FIG. 12 (step 1703).

Thereafter, as described above, the type inference expressions of the type check code section 1220 of FIG. 12 are sequentially executed (step 1
704). Then, as a result of the execution, the presence or absence of a type error is checked (step 1705).
707), if any, error processing (step 1706) is performed, and the inheritance processing ends. In this case, the type inference expression t0 => m1 :: t1 → t2 in FIG. 12 cannot be correctly executed. Because the type variable t0 is assigned the type type2, and the type type2 is
This is because it is found from FIG. 15 that the message m1: cannot be sent. Therefore, there is a type error, and as an error process, an error message is output together with the line number 007 attached to the type inference expression t0 => m1 :: t1 → t2. Therefore, it can be seen that the inheritance of the method m01: from the class type0 to the class type4 is not performed correctly.

The type checking method of the present invention is also effective for checking the consistency of programs in class updating (class definition change). When updating a class, it often affects the class that refers to the class.
It is necessary to check whether or not the effect can guarantee the integrity of the program of the affected class. If the integrity of the program cannot be guaranteed, it is necessary to update the class again and update the affected class. This test is
It becomes even more critical in systems that deal with persistent objects.

By checking the consistency of the program in this class update using the type checking program,
It can be done efficiently. This is because it is only necessary to run the type checker program that has already been generated without recompiling each affected class.

Now, the type checking method in the class update will be described with reference to the flow chart of FIG. 19 by using the definitions of the class type0 of FIG. 7 and the classes type1, type2 and type3 of FIG. The definition 1401 of the class type1 in FIG. 14 is updated. The content of the update is the type3 of the argument x of line 004
It is to be corrected to. In FIG. 19, first,
The updated definition of class type1 is compiled (step 1901). Class type at the end of compilation
It is checked whether there is a class that refers to 1 (step 1902). The reference information of the class is managed by each class object. Updated class type
If there is no class that refers to 1, the update is not affected and the process ends (step 1905).

However, if there is a class that refers to the updated class type1, the consistency of the program is checked for all the referenced classes (step 1910). Whether or not any class has a type error is checked (step 1903), and if there is no type error, it means that the update of the class type1 has been correctly performed, and the process ends (step 1905). If even one error exists, class type1
Cannot be updated correctly, error processing such as cancellation of update is performed (step 1920), and the process ends (step 1).
905).

FIG. 20 shows classes type0, type1, type2, and t.
This is a graph showing the reference relationship of ype3. Sections represent classes. That is, section 2001 is of class type1
, Section 2002 is class type2, Section 2003 is class t
ype3 and section 2004 represent class type0. The arrow indicates the reference relationship, and the direction of the arrow is the influencing direction. For example, if you update the class type1 in section 2001,
Affects class 0 of class 4. If you read the arrow in the opposite direction, it means that class type0 refers to class type1.

As described above, the class type0 is the class typ
As it refers to e1, it is affected by the update of class type1. Therefore, class type0 must perform a program consistency check. Here, FIG.
Returning to step 9, the process of checking the consistency of the program of the referenced class in step 1910 will be described using the case of class type0. First, information on class type0 is obtained (step 1911). This is to get a class object of class type0.

Next, the type checking programs of all the methods that refer to type1 are obtained (step 1912).
Then, the type checking program is executed for each (step 1913). Examine the results of the execution (step 1
903), if the type is incorrect, the method is class ty
Indicates that the program integrity could not be maintained due to the update of pe1. Therefore, error processing is performed (step 1920) and the process proceeds to the inspection of the next method. Class type
The method m01: of 0 refers to the class type1, but the update of the class type1 does not destroy the program consistency. In the type checking program for the method m01: in FIG. 12, the type inference expression referencing the class type1 is t0 => m1 :: t1 → t2, and the type variable t0 has the type type1.
However, the type type3 is assigned to the type variable t1. Class typ
Even if the argument of the method m1: in e1 changes to type3, it can be executed correctly.

The object-oriented programming language may provide a method of defining a class that represents a type with parameters. For example, define a list class with the element type as a parameter. This class defines the element type and uses it as a list of integers, a list of strings, etc. A single list class definition will generate a list class with various types of elements.

FIG. 21 is an example of a class definition in which a type is expressed by parameters. Line 001 represents the definition of class type5 ($ type) with type $ type as a parameter. Bold letters are reserved words for programming languages. 002 line, 0
Line 03 is as described in FIG. Line 004 represents that the method m5: takes an argument x1 and outputs an object of type type3. However, the type of argument x1 is parameter $ t
It is ype. Line 005 is the body of method m5:
The result of sending the message m2 to x1 is returned as the output of the method.

When using this class, type5 (type
2) and so on. At this time, the parameter $ type is replaced with type2. The parameter $ type cannot be replaced with any type. In the case of FIG. 21, parameter $ t
Since the message m2 is sent to the argument x1 which is type-declared by ype, at least the type that can be replaced with the parameter $ type must be the type that can send the message m2. If you don't check that you have specified the correct type for the parameter, you are more likely to get an error at run time. By using the type checking program, such checking can be performed without compiling the class type5 ($ type) using the parameter each time the type is specified in the parameter.

FIG. 22 shows a class type5 using parameters.
This is the type checking program for the method m5: defined in ($ type). In line 004 of FIG. 21, parameter $ typ
Since the type of the argument x1 which is type-declared by e is not fixed in the method, it is expressed by using the type variable t0 like the type of the external variable. This is the type variable declaration part 2
Registered at 210. The mold inspection code section 2220 is shown in FIG.
It is generated similarly to the second type check code part 1220.

For example, when the type type2 of FIG. 14 is used to generate a class type5 (type2) and the type checking program 2200 is executed, type2 is substituted for the type variable t0, and the type inference expression t0 =
> m2: → t1 can be executed correctly. However, the type typ in Fig. 14
When a class type5 (type1) is generated using e1 and the type checking program 2200 is executed, type1 is assigned to the type variable t0, and the type inference expression t0 => m2: → t1 cannot be correctly executed. Therefore, this check shows that the usage of type5 (type1) is incorrect.

The above-described embodiment is premised on a system that handles persistent objects. However, the type checking method of the present invention can also be applied to an object-oriented programming language using a file system or the like. FIG. 23 is a block diagram of the present invention using a file system. It is characterized by having a type information dictionary instead of the function of managing persistent objects and class objects in the above-mentioned embodiment.

A computer system 10 is the same as that shown in FIG. 2300 is a compiler, which reads the module definition 2320 of the program and executes the module execution code 2
330, a type information dictionary 2340, and a module type check program 2350 are generated. The type check program is executed by the type check program execution unit 2310 with reference to the type information dictionary 2340. If there is a type error as a result of the execution of the type checking program, that is, the type checking, the type checking program execution unit 2310 outputs the type error information. Configuration of type check program, generation method,
The execution method and the like are the same as those in the above-described embodiment.

FIG. 24 shows the structure of the type information dictionary. Information managed by each class object in the above-described embodiment is managed collectively. That is, depending on the model name,
It manages the information of the type and the class in which the type is defined. 2401 is a type name, which is an entry to the type and class information. A variable table 2402 is a list of variables that represent the static structure of the object. From the perspective of a module such as a function, it becomes an external variable. 2403 is type reference information. 2404 is a file name in which the class is defined. 2405 is a line number indicating the position of the class definition in the file. 2406 is a table of functions (modules) defined in the class. This corresponds to the method table (809 in FIG. 8) in the above embodiment. The function table 2406 includes a function name 2411 and a function specification 241.
2. Manage the execution code 2413 and the type checking program 2414.

Thus, without using the persistent object management function or class object, by generating the type information dictionary, the type check using the type check program can be performed.

Although the type checking program is generated at the time of compilation in the compiler in the above embodiment, the present invention is not limited to this, the class definition is directly analyzed to generate the type information, and the type information is generated based on the type information. A type checking program may be generated.

[0092]

As described above, according to the present invention, since it is possible to perform type checking independently of each phase of a conventional compiler such as syntax analysis, inheritance processing, class updating,
Efficient type checking can be performed when the same source program, such as a class definition having a type parameter, must be repeatedly type checked. Furthermore, since type checking can be delayed for compilation, it is not necessary to declare type definitions in advance and specify the order of compilation separately from class definitions, which alleviates restrictions on programmers due to strong typing. be able to.

[Brief description of drawings]

FIG. 1 is a configuration diagram when the present invention is applied to a persistent object management system.

FIG. 2 is a diagram showing each phase of a conventional general compiler.

FIG. 3 is a schematic diagram of a reference relationship between molds.

FIG. 4 is a schematic diagram of class inheritance.

FIG. 5 is a diagram showing each phase of the compiler according to the present invention.

FIG. 6 is a conceptual diagram of object types.

FIG. 7 is a diagram showing an example of a class definition.

FIG. 8 is a configuration diagram of a class object.

9 is a configuration diagram of a variable table in FIG.

10 is a configuration diagram of a method table in FIG.

FIG. 11 is a configuration diagram of a mold inspection program.

12 is a diagram showing an example of a type checking program corresponding to the method defined in the example of FIG.

FIG. 13 is a flowchart showing a processing procedure of compiling a plurality of classes and performing type checking.

14 is a diagram showing a definition example of a class referred to by the class definition of FIG. 7. FIG.

FIG. 15 is a diagram showing a list of types of information obtained by compiling the class definition of FIG.

FIG. 16 is a flowchart showing a processing procedure for executing a type checking program.

FIG. 17 is a flowchart showing a processing procedure of a type check associated with inheritance processing.

FIG. 18 is a diagram showing a class definition example for explaining the process of type checking associated with inheritance processing.

FIG. 19 is a flowchart showing a processing procedure of a type check accompanying a class update.

FIG. 20 is a diagram showing a directed graph showing a reference relationship of classes.

FIG. 21 is a diagram showing an example of a class definition having a type as a parameter.

22 is a diagram showing an example of a type checking program corresponding to the method defined in the example of FIG.

FIG. 23 is a system block diagram when the present invention is applied to an object-oriented programming language managed by files or the like.

FIG. 24 is a configuration diagram of a type information dictionary in FIG. 23.

[Explanation of symbols]

10 ... Computer system, 100 ... Compiler, 110 ...
Type check program execution unit, 112 ... Type error information, 12
0 ... Data management system, 121 ... Class definition, 130
... object management system, 131 ... class object, 133 ... method execution code, 135 ... type checking program.

Claims (14)

[Claims] 1. Compiling a first class definition, written in an object-oriented programming language, including method definitions and variable declarations, the compiling of a first class definition for a type of a class defined by the class definition. Generate type information, generate a type checking program for performing type checking on each of the methods based on the first type information, and compile a second class definition for a type to which the method refers And generating second type information regarding the type of the class defined by the class definition, and executing the type checking program corresponding to the method based on the first and second type information. Program type checking method. 2. The program type checking method according to claim 1, wherein the type information is generated by directly analyzing the class definition without compiling it. 3. The method according to claim 1, wherein the type checking program for performing the type checking of the method is generated only when the method refers to a type other than the type declared inside itself. A method for checking the type of a program. 4. The method according to claim 1, wherein in the step of generating the type checking program, a correspondence between a variable name of an external variable referenced by a corresponding method and a type variable representing the type of the variable is managed. A type variable declaration part and a type check code part showing a procedure for performing a type check using the type variable are generated, and the type check program is composed of the type variable declaration part and the type check code part. A method for checking the type of a program, characterized by: 5. The type checking code section according to claim 4, wherein the type argument is a type variable that cannot be directly inferred from the type argument of the corresponding method or the type declaration of the variable inside the method, and the type argument and the A method for checking the type of a program, characterized in that the type of the variable inside the method is a type constant. 6. The type checking code section according to claim 4, wherein the type checking code part has a type inference expression for inferring a type and a line number corresponding to the type inference expression, and the line number indicates the type inference expression. Information for indicating the position in the class definition that is the basis of generation is stored, and the type inference expression of the type checking program is executed based on the first and second type information, and a type error is detected. When it is detected, the line number corresponding to the type inference expression in which the error is detected is output, and the type checking method of the program. 7. The type variable declared in the type variable declaration part of the type checking program corresponding to the method, when performing the type checking of the method, according to claim 6, Substituting, executing the type inference expression, and when a type error is detected by the execution, the information about the error and the line number corresponding to the type inference expression are output. . 8. The method according to claim 6, wherein the type error is detected when the first and second type information cannot be referenced or the type cannot be assigned to the type variable. A method for checking the type of a program. 9. The inherited method according to claim 4, when inheriting the compiled method,
To check whether it can be correctly executed at the inheritance destination, assign the type of the corresponding variable declared in the class definition of the inheritance destination to the type variable of the type variable declaration part of the type checking program corresponding to the method, and A program type checking method characterized by executing a checking program. 10. The method according to claim 9, wherein the type of the variable in the class definition in which the inherited method is defined is stored as an initial value of the type variable in the type variable declaration part of the type checking program corresponding to the method. By doing so, the type checking method of the program is characterized in that the type checking is performed only when the type of the variable in the inherited class definition and the initial value are different. 11. The method according to claim 1, wherein, when performing an update that changes the class definition, a check is performed as to whether or not the update can guarantee the consistency with respect to the already compiled class definition. Type checking method for a program, which is performed by executing a type checking program corresponding to each method of a class that refers to the created class. 12. The information according to claim 1, wherein the class type information includes a class name, that is, a type name, a class definition of the class, a table of variables declared in the class definition and inherited variables, and a type reference. Information and a table of methods defined and inherited in the class definition,
A type checking method for a program, wherein information on the type of the class can be obtained by specifying a class name. 13. A first class definition using a type described as a parameter in an object-oriented programming language as a parameter, compiling without determining the value of the parameter, and first type information regarding the type including the parameter, When the first type checking program including the parameter is generated, and the second class definition is compiled to generate the second type information including the type assigned to the parameter, the assigned type becomes A type checking method for a program, wherein the checking of whether the first class definition is correct is performed by substituting the type into the first type checking program and executing the program. 14. A computer system comprising a compiler for compiling a class definition including a method definition and a variable declaration written in an object-oriented programming language, wherein the compiler relates to a type of a class defined by the class definition. Type information generating means for generating type information, first holding means for holding the generated type information, and a type for performing type checking on each of the methods based on the held type information. A type checking program generating means for generating a checking program; the system further includes a second holding means for holding the type checking program generated by the compiler; and type information about a type to be referred to by the method. Is generated, the type checking program corresponding to the method is Computer system characterized in that it comprises execution means for taking out from the holding means, to execute on the basis of information on the type.