| An extensible type system for representing and checking consistency of program components during the process of compilation -> Monitor Keywords |
|
An extensible type system for representing and checking consistency of program components during the process of compilationRelated Patent Categories: Data Processing: Software Development, Installation, And Management, Software Program Development Tool (e.g., Integrated Case Tool Or Stand-alone Development Tool), Testing Or Debugging, Including Analysis Of Program ExecutionAn extensible type system for representing and checking consistency of program components during the process of compilation description/claimsThe Patent Description & Claims data below is from USPTO Patent Application 20060242628, An extensible type system for representing and checking consistency of program components during the process of compilation. Brief Patent Description - Full Patent Description - Patent Application Claims CROSS REFERENCE TO RELATED APPLICATION [0001] This application is a continuation of U.S. application Ser. No. 10/607,601, filed Jun. 27, 2003, which is incorporated herein by reference in its entirety. TECHNICAL FIELD [0002] The present invention relates to type systems, and particularly, to a type system that is extensible to new and updated programming languages. BACKGROUND [0003] A type system is a system used in programming languages to aid in the detection and prevention of run-time errors. A programming language is "typed" if it contains a set of types that are declared for objects such as variables, functions, etc., and these types are checked versus a set of rules during compilation of a program written in the language. If the source code written in the typed language violates one of the type rules, a compiler error is determined. [0004] Typed intermediate languages for use in compilers have received significant study in the research community over the past few years. They enhance the reliability and robustness of compilers, as well as provide a systematic way to track and check information needed by garbage collectors. The idea is to have an intermediate representation that has types attached to it and that can be type-checked in a manner analogous to type-checking for source programs. However, a typed intermediate language is more difficult to implement because types that represent items made explicit during the compilation process are necessary. [0005] A typed intermediate language is even more difficult to implement if it must represent a number of different high-level programming languages. The different languages not only have different primitive operations and types, but the high-level programming languages have different levels of typing. For instance, some languages, such as assembly languages, are generally untyped. In other words, they have no type system. Of the languages that are typed, some are strongly typed while others are more loosely typed. For instance, C++ is generally considered a loosely typed language, whereas ML or Pascal are considered strongly typed languages. Further, some languages that are loosely typed have smaller sub-sets of the language that allow for a majority of the code sections within a program to be strongly typed, while other code sections are loosely typed. For example, C# and Microsoft Intermediate Language used in .NET (MSIL) allow this. Therefore, a typed intermediate language used to represent any of these high-level languages must be able to represent different types strengths. Likewise, the type system of such a typed intermediate language must be able to implement different rules depending on characteristics of the code being type checked. [0006] Another problem arises when a typed intermediate language is lowered throughout the process of compilation. The lowering of a language refers to the process of changing the form of a language from a higher level form, such as what a programmer would write, to a lower level, such as to an intermediate language. The language can then be further lowered from the intermediate language to levels closer to what a computer executes, such as machine-dependent native code. In order to type-check an intermediate language that is lowered to different levels during the compilation process, a different set of rules must be used for each representation. [0007] Attempts to create typed intermediate languages often fall short of solving the problems discussed above. For instance, Cedilla Systems' Special J compiler uses a typed intermediate language. However, this compiler is specific to the Java source language and therefore did not need to process multiple languages that may, for instance, have non-type-safe code. Additionally, this compiler only uses one set of rules for type-checking and therefore could not be used for multiple levels of compilation. In the research community, typed intermediate languages often tend to be highly specific to the source language and difficult to engineer (and design the types) for the multiple stages of compilation. SUMMARY [0008] A representation of types, type-checker, method and compiler are provided for checking consistency in various forms of an intermediate language. Specifically, the typed intermediate language is suitable for use in representing programs written in multiple (heterogeneous) source languages including typed and untyped languages, loosely and strongly typed languages, and languages with and without garbage collection. Additionally, the type checker architecture is extensible to handle new languages with different types and primitive operations. The representation of types, type-checker, method and compiler include various aspects. The various aspects may be used separately and independently, or the various aspects may be used in various combinations and sub-combinations. [0009] In one aspect, a method of type-checking a programming language in a compiler is provided. One or more rule sets is taken as input to a type-checker, which selects one or more of the rule sets based upon any one, or combination of two or more, of numerous criteria. Among them are stage of compilation, source language, architecture, and level of typing present in the language being type-checked. The language is then type-checked using the selected one or more rule sets, In another aspect, a compiler is provided with a type-checker that constructs one or more sets of rules based on any one, or combination of two or more, of numerous criteria. The rule sets can include one rule set corresponding to strong type-checking, one rule set corresponding to weak type-checking, and one rule set corresponding to representation type-checking. The weak rule set can allow more flexibility in typing, such as allowing type casts, while the representation rule set can allow dropped type information in parts of the intermediate program representation [0010] In another aspect, a programming interface is provided for constructing a plurality of rules for checking the consistency of an intermediate representation of a program. Checking the consistency of the intermediate representation can include providing a plurality of rules to a type-checker that applies a first set of rules to a one intermediate representation, and a second set of rules to a another intermediate representation, based on predetermined criteria. [0011] These and other aspects will become apparent from the following detailed description, which makes references to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS [0012] FIG. 1 is a flow diagram of a generic compilation process. [0013] FIG. 2 is a table listing showing a conversion of a source code statement into an high-level representation, and then to a machine-dependent low-level representation. [0014] FIG. 3 is a data flow diagram illustrating one embodiment of a compiler system for type-checking a typed intermediate language at various stages of compilation. [0015] FIG. 4 is a block diagram of a type-checker for use in a compiler system. [0016] FIG. 5 is a flowchart for one possible procedure for choosing a rule set to be applied by a type-checker. [0017] FIG. 6 is a direct graph diagram showing a hierarchical relationship between types. [0018] FIG. 7 is a direct graph diagram showing the addition of a type to a hierarchical relationship between types. [0019] FIG. 8 is a flow chart of a method for checking an instruction against a type rule in a type-checking system. Continue reading about An extensible type system for representing and checking consistency of program components during the process of compilation... Full patent description for An extensible type system for representing and checking consistency of program components during the process of compilation Brief Patent Description - Full Patent Description - Patent Application Claims Click on the above for other options relating to this An extensible type system for representing and checking consistency of program components during the process of compilation patent application. ### 1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored. 3. Each week you receive an email with patent applications related to your keywords. Start now! - Receive info on patent apps like An extensible type system for representing and checking consistency of program components during the process of compilation or other areas of interest. ### Previous Patent Application: System and method for conditional tracing of computer programs Next Patent Application: Process for preparing design procedure document and apparatus for the same Industry Class: Data processing: software development, installation, and management ### FreshPatents.com Support Thank you for viewing the An extensible type system for representing and checking consistency of program components during the process of compilation patent info. IP-related news and info Results in 0.30641 seconds Other interesting Feshpatents.com categories: Daimler Chrysler , DirecTV , Exxonmobil Chemical Company , Goodyear , Intel , Kyocera Wireless , 174 |
* Protect your Inventions * US Patent Office filing
PATENT INFO |
|