Cross-Project Namespace Compiler and Method

This invention relates to compiling computer programs written in a high level programming language into executable form, and, more particularly, relates to the availability of program objects for reference within client program units external to the unit in which the objects are declared.

Computers operate under the control of a program consisting of coded instructions. Typically, programs are first written in a high level programming language, such as BASIC, PASCAL, C, C++, or the like, which are more readily understood by humans. The high level language statements of the source code are then translated or compiled into the coded instructions executable by the computer. Typically, a software program known as a compiler is used for this purpose. The terms, "source code" and "object code," are often used to describe the form of a program prior to and after compiling, respectively. Accordingly, the term "source code" generally refers to a program in its high level programming language form. "Object code," on the other hand, generally refers to the program in the form of the coded instructions generated by the compiler which are executable on a computer.

Typically, the source code of a programming language is organized in one or more program units, such as procedures, functions, blocks, modules, projects, packages and/or programs. These program units allow larger program tasks to be broken down into smaller units or groups of instructions. For example, in many programming languages, groups of instructions that are repeated frequently in a program can be organized into a single procedure or function. Each place in the source code where the group of instructions would otherwise be repeated, a reference (known as a procedure or function "call") to the procedure or function is instead used. Also, in some programming languages, related statements, procedures and functions are grouped together in program units, such as modules and the like. Some programming language systems are further organized in higher order program units, such as projects or the like, which may include one or more related lower order program units, e.g., modules. Considerable programming effort can be saved in subsequent programming work, by incorporating well-designed modules and projects from previous programs.

Programming effort also can be conserved through the use of a program unit known as a type library. Type libraries contain information defining the types of various program elements which may be incorporated within computer programs written in different programming languages. So that the information can be incorporated in programs written in different programming languages, the type information is made available through a standard procedural interface to application programs, including compilers, and interpreters. Type libraries and their use is described in U.S. patent application Ser. No. 07/959,056, entitled "Method and System for Interfacing to a Type Library," which is hereby incorporated by reference.

In source code, names (also known as identifiers) are generally explicitly assigned in declaration statements, to various program elements, such as variables, functions, procedures, and constants. (In some languages, names also may be assigned implicitly. For example, in FORTRAN, names beginning with i,j, . . . ,n are implicitly integer variables.) Typically, the declaration statements recite a name which is to be assigned to a program element , along with attributes of the program object (e.g. integer, string, array, etc . . . ). Other statements which operate on program elements, such as procedure calls, expressions, assignments, and the like, make reference to the program elements using their assigned names.

High level programming languages generally impose rules governing the scope of names (i.e. where a particular name is available in a program for referencing the associated program object). With statically scoped programming languages, names have a scope commensurate with the program unit in which they are declared. For example, names declared in a procedure generally are only available (i.e. in scope) within the procedure. Names declared in a module or project are generally available only within the module or project (and in its subunits). The names available within a particular program unit are generally referred to as the namespace of the unit.

As a part of the compiling process generally known as "binding" names to program elements, name references in the source code are matched to program elements currently in scope. Generally, to match a name to a program elements, previous compilers search the namespaces of the program units in which the name reference is located from a lowest order unit (e.g. a current procedure) to a highest order unit (e.g. a current project). If this search doesn't locate a program element with a matching name in these namespaces, the compiler generates an error.

In writing source code, it is sometimes desirable to make the names of program elements (hereafter "external program objects") declared within one program unit available for referencing within another program unit (hereafter "client program unit"). For example, it may be useful to include a function call within a client project which references an external function declared in another project. By making the external function available for reference within the client project, one can avoid having to declare the external function anew in the client project. Further, any subsequent changes to the external function can then be made to a single declaration of that function, thus avoiding possibly inconsistent multiple declarations of the function. Similar advantages attain for variables, constants, and other program elements.

In previous programming language systems, some mechanisms have been provided which permit access to external program elements. With some programming languages, such as Ada and Modula, the programmer writes an explicit export list in the source code for a program unit which contains the names of program elements which are to be made available for access within other, client program units. With some other programming languages, explicit import lists are used to identify external program elements which are to be made accessible within a client program unit. The Modula programming language, for example, employs both explicit export and import lists. As another example, the Ada programming language uses explicit import lists for separately compilable program units, and a declarations section which serves some of the same purposes as an export list. Such export or import lists generally take the form of a header file associated with the program unit or a statement within the program unit. The difficulty with these mechanisms is that they place an added burden on the programmer to maintain and update such lists as access to additional external program elements becomes necessary. The lists also add to the length and complexity of the source code, resulting in an increased opportunity for coding errors.

Additionally, in some programming language systems, access to external program elements within a client program unit is made with a "qualified" name reference. The name referencing a program element is qualified by adding or prefacing a name identifying the program unit in which it is declared. Typically the program unit name and program element name are separated by a "." or other delimiter. For example, an external program element named "PObj" which is declared in the program unit "PUnit" may be accessed with the qualified name, "PUnit.PObj." Where the source code is organized in several orders or levels of program units, the qualified name reference may comprise a string of program unit names. For example, a qualified name reference to access a function, "Func," declared in a module, "Mod," within a project, "Proj," may require the string of names, "Proj.Mod.Func." Again, this mechanism places an added burden on the programmer in that the program unit in which an external program element is declared must be explicitly recited in the source code each time the element is referenced. Accordingly, the programmer must mentally or otherwise keep track of numerous external program elements and the program units in which they are declared. With explicit qualification, the programmer also is required to recite a lengthier name reference to access external program elements, thus increasing the possibility of coding errors.

An object of the invention is to permit references to external program elements within a client program unit without resort to explicit qualification. Another object is to permit references to external program elements without explicit, programmer-written export or import lists of externally provided program elements. Yet another object of the invention is to enlarge the namespace of program units to include at least some external program elements of other program units. A further object of the invention is to provide access to external program elements of type libraries substantially equal to the access to external program elements of native program units.

The present invention provides a compiler and method to make external program elements available for access within a client program unit without export lists, import lists, or qualified name references.

According to the invention, the source code of a program is organized by the programmer in a plurality of projects, or like program units. (For expository convenience, such program units are hereafter referred to as "projects".) In each project of the source code, the programmer may include references to other projects and references to type libraries. The project which includes such references is said to be a "client" project. The projects and type libraries indicated by the references are said to be "directly referenced" by the client project. The directly referenced projects may, in turn, include references to yet other projects and type libraries, which are said to be "indirectly referenced" by the client project. Within each client project of the source code, the programmer also may include unqualified name references to external program elements declared in the client project's directly referenced projects and type libraries. Accordingly, by creating a reference in a client project to another project or type library, the public names of program elements in the referenced project or type library are made available for unqualified reference in the client project without requiring an explicit export or import list of program elements.

To bind unqualified names to program elements during compiling, the namespaces associated with the client project are searched for a corresponding name. In a preferred embodiment of the invention, the namespaces of program units in the client project are searched in a hierarchical order from that of the lowest order unit containing the unqualified name to the client project's namespace. The namespaces of any projects and type libraries that are directly referenced by the client project also are searched for a corresponding name. In the preferred embodiment, the namespaces of the directly referenced projects and type libraries are searched in an order in which they are referenced within the client project. The search is completed at the first namespace in the search order which contains the corresponding name. The unqualified name is then bound to the program element associated with the corresponding name. If no corresponding name is found after searching these namespaces, the compiler generates an error message to notify the programmer.

In the preferred embodiment of the invention, the same binding process is applied to bind names which reference external program elements from another project as is applied when binding names which reference external program elements from type libraries. Accordingly, type libraries (which are language independent program units) are treated by the compiler as if a native program unit of the programming language. Further, in some embodiments of the invention, the process of binding name references to external program elements is accomplished utilizing an identical procedural interface for both projects and type libraries.

In a further aspect of the preferred embodiment of the invention, references within a project to other projects and type libraries are created automatically by a host development environment. Further, a list of such referenced projects and type libraries in a project is modifiable through a user interface of the development environment. Accordingly, such project and type library references are generated implicitly, and cannot be expressed in the preferred programming language.

Additional features and advantages of the invention will be made apparent from the following detailed description of a preferred embodiment which proceeds with reference to the accompanying drawings.

FIG. 1 is a block diagram of a source code organized in procedures, modules, and projects, and containing names in a client project, which reference external program elements according to the invention;

FIG. 2 is a block diagram illustrating a namespace hierarchy of the source code of FIG. 1;

FIG. 3 is a block diagram illustrating the namespaces of the procedures, modules and projects of the source code of FIG. 1 ordered according to the hierarchy of FIG. 2;

FIG. 4 is a flow chart of a conventional process for compiling source code;

FIGS. 5 and 5A are a flow chart of a binding method according to a preferred embodiment of the invention which is incorporated in a compiling process, such as the compiling process of FIG. 4, to compile source code having name references to external program elements, such as the source code of FIG. 1; and

FIG. 6 is a block diagram of a computer system that may be used to implement a method and apparatus embodying the invention for compiling source code having name references to external program elements, such as the compiling process of FIG. 4 including the binding process of FIGS. 5 and 5A.

With reference to FIG. 1, an exemplary source code 10 which may be compiled according to the invention is organized in procedures 14-16, modules 20-24, projects 28-31, and type libraries 34. In the preferred embodiment of the invention, a programmer writes the source code 10 according to a syntax of Microsoft Corporation's Visual Basic.RTM. for applications language system. The source code can be written using a word processing software or editor. Preferably, the source code is written using a program development software (referred to herein as an integrated development environment or IDE) which provides a plurality of software tools with a single convenient user interface for creating and editing source code.

In accordance with the invention, the source code 10 may contain one or more names within a client project which reference program elements declared in other projects without the programmer providing qualifiers, or any import or export list of program elements. Such unqualified names are bound to elements external to the client program unit by a compiler using a novel binding method described more fully below.

In writing the source code 10, a programmer preferably organizes the source code 10 into program units referred to herein as projects. In the programming language of the preferred embodiment, a project is a collection of modules, references 36-39 to other projects, and references to application type libraries. For example, the project 28 in the source code 10 contains the modules 20-22, and references 36, 37 to the projects 29 and 30. As another example, the project 29 contains modules (not shown), a reference 38 to the project 31, and a reference 39 to a library 34.

The programming language of the preferred embodiment, Visual Basic.RTM., is designed for use in writing custom programs that integrate into various commercially available application software, such as Microsoft Excel.RTM., Access.RTM., and Word, so as to customize these applications. Integration with application programs is accomplished, in part, by providing application type libraries for each application, such as the type library 34, containing program elements used for interacting with or controlling the application. The type library 34 preferably conforms to the model defined in U.S. patent application Ser. No. 07/959,056, entitled "Method and System for Interfacing to a Type Library," previously incorporated herein by reference.

In the preferred embodiment, the references in a project to other projects and type libraries are created automatically by the IDE and can be modified by a programmer through interaction with the user interface of the IDE, such as by appropriate menu selections and text entry, or otherwise. In this case, the reference may take the form of an exclusively machine-readable code in a file containing the source code 10. In alternative embodiments of the invention these references to other projects and type libraries may be created by the programmer writing statements in the source code 10 such as the following:

However, in the preferred embodiment of the invention, a list of referenced projects and libraries are created outside the programming language through commands provided in the user interface of the integrated development environment. In the preferred embodiment, references to projects and libraries are ordered, such as by an order in which the references appear in a project or in which the references were created by a programmer.

By creating a reference in a project to another project or library, a relationship between the projects and/or libraries is formed. The project containing the project or library reference is said to be a client project of the project or library that it references. The project or library that the client project references is said to be a directly referenced project or library of the client project. For example, because the project 28 contains references to the projects 29, 30, the projects 29, 30 are directly referenced projects of the client project 28. Directly referenced projects may, in turn, include references to yet other projects and type libraries, which are said to be "indirectly referenced" by the client project. For example, the project 31 and the library 34 (which are each referenced by the directly referenced project 29 of the client project 28) are considered to be indirectly referenced by the client project 28.

A module in the programming language of the preferred embodiment is a container for program elements, such as procedures, and data (referred to as module "members"), as well as type declarations. In the source code 10, for example, the module 20 contains the procedure 14, and the module 23 contains procedures 15 and 16. Data members can be declared as cqnstants, variables, or records, and are typically declared in statements such as the following:

(Words presented in bold text in the statements illustrated herein are reserved words of the programming language.) Constants and variables are intrinsic (language defined) data elements of the programming language. Records are data elements defined by a type declaration as a collection of intrinsic data elements, and/or other records. The following type declaration, for example, defines a particular record, "bar," as a collection containing two intrinsic data elements, an integer "x" and a single "y".

Procedures in the programming language of the preferred embodiment are groups of statements for performing one or more operations. (The preferred programming language refers to procedures which return a value as a "function." For expository convenience, the term "procedure" is used herein to refer to both procedures and functions.) The statements include language defined operations on intrinsic data elements, calls to other procedures, and the like. Procedures may also include declarations of local variables used within the procedure. For example, local variables in procedures are declared in statements such as the following:

which appear within a procedure statement such as the following:

The exemplary statements (1)-(6) above each declare a name for a particular program element. Other statements which perform operations on the program element, reference the element using its declared name. (The names appearing in such non-declarative statements are referred to herein as referencing names or name references.) In the syntax of the programming language used in the preferred embodiment, names (also known as identifiers) are strings of characters which are subject to the following four rules: (1) begin with a letter, (2) contain only letters, numbers, and the underscore character, (3) are no longer than 255 characters, and (4) contain no reserved words. However, according to the programming language of the preferred embodiment, the scope or availability of a name for referencing its associated program element is limited to particular ones of the procedures, modules, or projects in which the source code 10 is organized by the programmer.

With reference to FIG. 2, the scope of availability of names within the source code 10 is determined according to the organization of the source code by the programmer into various program units, and further according to a namespace hierarchy 48. A namespace is a collection of names for program elements available within a procedure, module, or project and includes the names of each program element declared within the unit. Thus, by virtue of the programmer including a program element's declaration within a program unit, the program element's name is in the namespace of that program unit. More specifically, each procedure 14-16 of the source code 10 (FIG. 1) has a namespace 42 (herein referred to as a "local variable namespace") which includes the names of local variables and constants declared (explicitly or implicitly) within the particular procedure. Modules 20-24 (FIG. 1) preferably have two separate namespaces. One namespace 44 of each module (referred to herein as a "variable namespace") contains names of data members and procedures of the module. Each module also has a separate namespace 45 (referred to herein as a "type namespace") which contains names of types declared in the module. Each project 28-31 (FIG. 1) has corresponding namespaces 46, 47 (herein referred to as a "project variable namespace" 46 and a "project type namespace" 47). To enable explicit qualification (described below) of variables, procedures, and types, a project's variable and type namespaces 46, 47 also both include a name of the project itself and names of modules contained in the project. Within each namespace, names are required to be unique. In other words, no two program elements in a namespace may be assigned identical names.

In the preferred embodiment, the namespaces 42, 44-45, and 46-47 of the program units in the source code 10 (FIG. 1) are ordered according to the namespace hierarchy 48. In the hierarchy 48, the local variable namespace 42 of a procedure is at a lowest level. Above the local variable namespace 42 is the variable namespace 44 and type namespace 45 of a module containing the procedure. A type namespace 46 and a variable namespace 47 of a project containing the module is at a highest level in the hierarchy 48.

With reference to FIG. 3, when ordered according to the hierarchy 48, for example, namespaces 50-62 for the procedures 14-16, modules 20-24, projects 28-31, and library 34 of the source code 10 are ordered as follows. Variable and type namespaces 50-54 for the projects 28-31 and library 34 are considered to be at the highest level. Under the namespaces 50 of the project 28 are the type and variable namespaces 55-57 of the modules 20-22 within the project. The local variable namespace 58 of the procedure 14 which is contained within the module 20, is under the namespaces 55 of the module 20. Likewise, namespaces 59-60 of the modules 23-24 which are contained within the project 30, are under the namespaces 51 of the project 30. The local variable namespaces 61-62 of the procedures 15, 16 also are under the namespaces 59 of the module 23 which contains these procedures.

Referring again to FIG. 1, in the programming language of the preferred embodiment, names appearing in a current program unit can reference (without qualification) any program elements whose names are included in the current program unit's namespace or those namespaces above it in the hierarchy 48 (FIG. 2) of any program unit containing the current program unit. For example, a name appearing in the procedure 14 can reference any program element whose name resides in a local variable namespace of that procedure, or in the namespaces of the module 20 and project 28 in which the procedure is located. Names also can reference data members, which have been declared as public, of other modules in the same project without qualification. For example, an identifier residing in the procedure 14 also can reference names of public module members in the variable namespace of modules 21 or 22. Further, according to the invention, names (without qualification) also can reference program elements whose names reside in the namespaces of another directly referenced project or type library, or their module's public data members. For example, a name appearing in the procedure 14 can reference program elements whose names reside in the namespaces of projects 29 and 30, and names of public data members of modules 23 and 24.

To reference program elements whose names are not currently in scope (e.g., a program element whose name resides in the namespace of an indirectly referenced project), name references must be qualified by prefixing additional names (known as "qualifiers") separated by a period (".") which specify a path to the project in which the name resides. For example, a name, e.g., "anelement," appearing in the procedure 14 can reference a program elements whose name resides in the namespace of the project "S" 31 (which is not directly referenced by program P 28) by prefixing names "Q" and "S" of projects 29, 31 in a path of project references 36, 38 from the project "P" 28, such as the following:

Qualified names are interpreted as if they appeared in the program unit specified by its qualifiers. Explicit qualification of name references can always be used even when unnecessary (such as when the name of the program element resides in the namespace of a directly referenced project).

Referring now to FIG. 4, source code, which may contain one or more names referencing program elements whose names reside in the namespaces of other projects and type libraries, is compiled according to the invention by a process 70 into executable code for a computer program. The compiling process 70 can comprise various subprocesses that are known in the art (and therefore not explained in detail herein), such as lexical analysis 72, syntax analysis 74, intermediate code generation 76, code optimization 78, executable code generation 80, table management 82, and error handling 84, and additionally includes the steps of a binding method 90 illustrated in FIG. 5. With the addition of the binding method 90 described more fully below, the compiling process is able to compile source code having names references to external program elements whose names reside in the namespaces of directly referenced projects and libraries (e.g., the source code 10) without name qualification, or export and import lists for program elements. Preferably, the compiling process 70 is performed by a software program known as a compiler (not shown) running on a general purpose computer (see FIG. 6).

In the compiling process 70, lexical analysis 72 is first performed on source code to separate the source code into various lexical constructs or tokens of the programming language, including identifiers, keywords, operators, literals, and comments. Syntax analysis 74 also is performed to separate the source code into syntax structures, such as declaration statements, loop statements, expressions, and the like. Executable code for each of these language structures is then generated 76, 78, 80. Code generation may be done in any number of stages, but preferably includes generating 76 an intermediate code form of the program, then performing various optimizing procedures 78 to reduce the size and increase the speed of the resulting program before generating 80 executable code for the program.

During the above stages 72, 74, 76, 78, 80 of the compiling process 70, the compiler determines which names reside in the various namespaces of the procedures, modules, and projects in the source code. This determination (indicated generally as table management 82) is made as the compiler interprets declaration statements appearing in those procedures, modules and projects, such as the statements (1)-(5) above. The compiler stores the names for each namespace in a data structure sometimes referred to in the art as a symbol table. These symbol tables are preferably implemented as hash tables or binary search trees, but alternatively may be implemented as any of various list or set collection structures known in the art.

With reference to FIGS. 5 and 5A generally, as a part of the compiling process referred to above as intermediate code generation 76 (FIG. 4) (although alternatively incorporated in another of the stages of the compiling process 70), the compiler performs the method 90 for binding names in source code to program elements. In accordance with the programming language of the preferred embodiment, name references which require binding appear in procedures and modules. To bind these name references, the compiler locates a name of a program element identical to the name reference by searching the namespaces of various procedures, modules, and projects of the source code in a particular order. The order in which the compiler searches the namespaces preferably begins at a namespace of the hierarchy 48 (FIG. 2) for a current procedure or module where the referencing name appears. The order then proceeds up the hierarchy 48 to the namespace of a current project, and proceeds to the namespaces in hierarchies of each project directly referenced by the current project.

More specifically, when the compiler encounters a name reference in the source code requiring binding, the compiler performs the steps of the method 90. The method 90 is performed for both names which reference types and names which reference data or procedure members. However, in the case of names which reference types, the type namespace of the respective module or project is searched. In the case of names which reference data and procedures, the variable namespaces of the respective procedure, module or project is searched. Whether a name references program elements in a type or variable namespace is determined by the compiler from its context in the source code (i.e. where it appears in a source code statement) through the syntax analysis subprocess 74 (FIG. 4).

As indicated at step 92, the compiling process 70 begins at step 100 or 102 depending on whether the name reference is encountered at the procedure or the module level. If the name reference appears in a procedure (the "current procedure"), the compiler begins at step 100 by searching the namespace of that procedure for an identical name. However, if the name reference appears instead at the module level, the compiler begins at step 102 by searching the namespace of that module. For example, if the name reference appears in the procedure 14 (FIG. 1), the compiler first searches that procedure's namespace. However, if the name reference appears external to the procedure 14, but within the module 20 (FIG. 1), the compiler first searches the module's namespace.

After the initial namespace searched at the step 100 or 102, the compiler searches namespaces in a particular search order for a matching name. As indicated at step 101 (and subsequent steps 103, 105, 108, 117, and 120), whenever the namespace (or namespaces) searched at a particular step (e.g., steps 100, 102, 104, 106, and 116) in the search order doesn't contain a matching name, the compiler continues by searching the namespace (or namespaces) at the next step of the search order. Initially, the search order proceeds at the next level up in the hierarchy 48 from the level where the name reference appears, i.e. the namespace of the current module (step 102), and then the project variable namespace (step 104). For example, for a name reference appearing in the procedure 14 (FIG. 1), the compiler next (after an initial search of the procedure's namespace) searches the respective type or variable namespaces of the module 20 (depending on whether the name references a type data or procedure program element) at step 102, then that of the project 28 at step 104. If the name reference appears in the module 20, the compiler searches the respective type or variable namespace of the project 28 at step 104 after its initial search of the respective type or variable namespace of the module 20.

The search order continues with a search of the namespaces of remaining modules in the current project for a public name matching the name reference (step 106). For example, for any name references appearing in the procedure 14 or module 20 (FIG. 1), the compiler also searches the namespaces of the other modules 21 and 22 in the same project 28 for a matching public name.

Then, for each project or library directly referenced by the current project, the project namespace of the directly referenced project is searched (step 116), and the namespaces of each module in the directly referenced project or library is searched for a matching public data member name (step 118). The namespaces of directly referenced projects and libraries (and their respective modules) preferably are searched in a predetermined order, such as in the order by which the projects and libraries are referenced in the current project. For example, for a name reference appearing in the procedure 14 (FIG. 1), the compiler's search order includes the namespaces of the projects 29, 30 which are directly referenced by the current project 28. The compiler's search order also includes the public names in the namespaces of the modules 23, 24 in those directly referenced projects 29, 30. The namespaces of the project 31 and library 34 which are indirectly referenced by the current project 28 are not searched.

At the steps 106 and 118, where the namespaces of modules are searched for a matching public name, the compiler generates an ambiguity error message (step 110) if the namespaces of more than one of the modules contain public names matching the referencing names (steps 107,119).

If, after searching namespaces in all directly referenced projects and libraries without finding any matching name (i.e., no other directly referenced project or library namespaces remain to be searched, step 114), the name is considered to be declared implicitly as a variable having a default type (step 122). The name is then added to the namespace of the current procedure or module in which it appears. However, if implicit declaration of variables is not permitted, an error is instead generated by the compiler. In the preferred embodiment of the invention, a statement can be included in the source code which sets a compiler option to prevent implicit declaration of variables, such as by the following:

When a name identical to the referencing name is found in the namespace (or namespaces) searched at any of the steps 100, 102, 104, 106, 116, or 118 in the search order, the search is considered complete (steps 101, 103, 105, 108, 117 and 120) and the method 90 branches to step 124. For example, the search is halted at a first of the referenced projects or type libraries whose namespace(s) are found to contain the matching name (steps 117, 120) without continuing to search the namespace(s) of any remaining referenced projects or type libraries. The compiler then binds the referencing name to the matching name of a program element (step 124). After completing any of the steps 110, 122, or 124, the compiler has completed the process 90 of binding the particular referencing name to a name of a program element. The compiler returns to the compiling process 70 (e.g., at intermediate code generation subprocedure 76) until another name requiring binding is encountered in the source code.

The compiler in some embodiments of the invention utilizes the procedural interface for type libraries defined in U.S. patent application Ser. No. 07/959,056, entitled "Method and System for Interfacing to a Type Library," previously incorporated herein by reference, to both search the namespace of a directly referenced library and to bind a name reference to a program element whose name resides therein. For example, for a name reference appearing in a module (not shown) of the project 29 (FIG. 1), the compiler utilizes the type library procedural interface to search the namespace of the library 34 (FIG. 1) at steps 114 and 118, and if a matching name is found therein, to bind to the named program element. In the language system of the preferred embodiment, an identical procedural interface is provided for interfacing with projects. Accordingly, searching namespaces associated with projects and binding to program elements named therein can be accomplished through an identical procedural interface.

FIG. 6 is a block diagram of a computer system 200 which is used to implement a method and apparatus embodying the invention. Computer system 200 includes as its basic elements a computer 202, input device 204 and output device 206.

Computer 202 generally includes a central processing unit (CPU) 208 and a memory system 210 that communicate through a bus structure 212. CPU 208 includes an arithmetic logic unit (ALU) 213 for performing computations, registers 214 for temporary storage of data and instructions and a control unit 216 for controlling the operation of computer system 200 in response to instructions from a computer program such as an application or an operating system.

Memory system 210 generally includes high-speed main memory 218 in the form of a medium such as random access memory (RAM) and read only memory (ROM) semiconductor devices and secondary storage 220 in the form of a medium such as floppy disks, hard disks, tape, CD-ROM, etc. and other devices that use optical or magnetic recording material. Main memory 218 stores programs such as a computer's operating system and currently running application programs. Main memory 218 also includes video display memory for displaying images through a display device.

Input device 204 and output device 206 are typically peripheral devices connected by bus structure 212 to computer 202. Input device 204 may be a keyboard, modem, pointing device, pen, or other device for providing input data to the computer. Output device 206 may be a display device, printer, sound device or other device for providing output data from the computer.

It should be understood that FIG. 6 is a block diagram illustrating the basic elements of a general purpose computer system; the figure is not intended to illustrate a specific architecture for a computer system 200. For example, no particular bus structure is shown because various bus structures known in the field of computer design may be used to interconnect the elements of the computer system in a number of ways, as desired. CPU 208 may be comprised of a discrete ALU 213, registers 214 and control unit 216 or may be a single device in which these parts of the CPU are integrated together, such as in a microprocessor. Moreover, the number and arrangement of the elements of the computer system may be varied from what is shown and described in ways known in the art (i.e., multiple CPUs, client-server systems, computer networking, etc.).

Having described and illustrated the principles of our invention with reference to a preferred embodiment, it will be recognized that the preferred embodiment can be modified in arrangement and detail without departing from such principles. In view of the many possible embodiments to which the principles of our invention may be put, it should be recognized that the detailed embodiments are illustrative only and should not be taken as limiting the scope of our invention. Rather, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.