Apparatus and method for software system management using second-order logic

Abstract

A software system manager to achieve second-order logical management of a software system model is described. The system relies upon a second-order logic system description that uses variable functors with specified import predicate arguments and export predicates. The second-order logical system description includes a second-order system model, a second-order rule set, and a second-order operation module. The second-order system model defines a set of existing program files, the second-order rule set defines a set of operations that can be performed on the existing program files, and the second-order operation module specifies an operation to be executed by the secondorder rule set on the set of existing program files. The second-order logic system description is used to generate a set of system construction commands. The system construction commands specify the commands necessary to transform the existing program files into intermediate object files that are used to produce an executable program.

Claims

I claim:

1. A computer readable memory to direct a computer to function in a specified manner, comprising:

executable instructions stored in said memory, said executable instructions including a second-order logic system description including:

a second-order system model that defines a set of existing source code program files stored in said memory,

a second-order rule set that defines a set of software system management operations that can be performed on said set of existing source code program files, and

a second-order operation module that specifies a desired software system management operation to be executed in accordance with said second-order rule set on said set of existing source code program files,

wherein said executable instructions of said second-order logic system description include instructions specifying variable functors with specified import predicate arguments and export predicate arguments; and

wherein said second-order logic system description directs said computer to produce system construction commands that are used to create and name a set of intermediate object code files that are used to generate an executable program from said set of existing source code program files.

2. The computer readable memory of claim 1 wherein said existing program files stored in said memory include a first set of program files and a second set of program files, said first set of program files including executable instructions to perform the operation of a tool controller interacting with a plurality of compilers, linkers, and said second set of program files, said tool controller processing said system construction commands to transform said second set of program files into said executable program.

3. The computer readable memory of claim 1 wherein said executable instructions of said second-order logic system description further include transformation engine executable instructions used to transform said second-order system model into a first-order system model.

4. The computer readable memory of claim 3 wherein said transformation engine executable instructions include Prolog interpreter instructions that process said first-order system model to generate said system construction commands.

5. The computer readable memory of claim 3 wherein said first order system model includes a data structure specifying a module name, import predicate arguments, export predicate arguments, internal predicates, a functor, and term arguments.

6. The computer readable memory of claim 5 wherein said import predicate arguments include a data structure that specifies a module name, import predicate variables, export arguments, local predicates, and a predicate functor.

7. A computer readable memory storing a first set of instructions that are executed by a computer to form a tool controller which interacts with a plurality of compilers, linkers, and source code program files to transform said source code program files into an executable program, comprising:

executable instructions stored in said computer readable memory as a second set of instructions that are executed by said computer to form:

a second-order rule set defining a set of processing operations performed on said source code program files, and

a user interface

to define a second-order system model that specifies said source code program files, and

to select a desired second-order processing operation to be executed on said source code program files to from a set of system construction commands that are applied to said tool controller, wherein said second-order rule set, said second-order system model, and said second-order processing operation of said executable instructions include instructions specifying import predicate arguments and export predicate arguments.

8. The computer readable memory of claim 7 wherein said second-order rule set, said second-order system model, and said second-order processing operation produce a first set of executable commands to create and name a set of intermediate object files that are used to change said source code program files into an executable program.

9. The computer readable memory of claim 7 wherein said second set of instructions further include transformation engine instructions used to transform said second-order system model into a first-order system model.

10. The computer readable memory of claim 9 wherein said transformation engine instructions include Prolog interpreter instructions that process said first-order system model to generate said system construction commands.

11. The computer readable memory of claim 9 wherein said first order system model includes a data structure specifying a module name, import predicate arguments, export predicate arguments, internal predicates, a functor, and term arguments.

12. The computer readable memory of claim 11 wherein said import predicate arguments include a data structure that specifies a module name, import predicate variables, export arguments, local predicates, and a predicate functor.

13. A method executed by a computer under the control of a program, said computer including a memory for storing said program, said method comprising the steps of:

receiving in said computer a second-order logic system description including variable functors with specified import predicate arguments and export predicate arguments, said second-order logic system description further including

a second-order system model that defines a set of existing source code program files,

a second-order rule set that defines a set of operations that can be performed on said set of existing source code program files, and

a second-order system query that specifies a desired operation to be executed by said second-order rule set on said set of existing source code program files;

applying said second-order logic system description to a query engine running on said computer system to generate system construction commands; and

executing said system construction commands on said computer system to form a set of intermediate object code files that are used to generate an executable program from said set of existing source code program files.

14. The method of claim 13 wherein said executing step includes the steps of

running a first set of program files on said computer system to form a tool controller interacting with a plurality of compilers and linkers; and

using said tool controller to process said system construction commands in relation to said existing program files to form said executable program.

15. The method of claim 13 wherein said applying step includes the step of transforming said second-order system model into a first-order system model.

Description

BRIEF DESCRITPION OF THE INVENTION

This invention relates generally to the management of large software systems. More particularly, this invention relates to a software system manager employing variable functors with specified import predicate arguments and export predicate arguments to achieve second-order logical management of a software system model.

BACKGROUND OF THE INVENTION

Software system management tools define software elements, their interdependencies, and the rules that are required to construct a software product. These tools are necessary in view of the fact that a large software system typically includes a large number of individual source code programs that are compiled and then linked into a single executable program. This results in a number of software system management requirements. For example, a source code program may have a number of versions. Therefore, it is necessary to identify the proper version to be used in constructing the executable program. In addition, each source code program may require a distinct compiler. Thus, a mechanism must be developed to coordinate a source code program with the appropriate compiler. Software system management tools are also used to track program bugs. The most commonly used system modeler is MAKE.RTM., which runs on the UNIX.RTM.operating system.

FIG. 1 illustrates a prior art software system management apparatus 20. The apparatus 20 includes a central processing unit 22 which communicates with a memory module 24 and a hardware user interface 26 through a bus 28. A user working at the hardware user interface 26 inputs a rule-based description of a software system, which is downloaded into memory module 24. The rule-based software configuration description 30 is an integrated description of software elements, their interdependencies, and the rules that are used to construct a final product.

The memory module 24 stores a number of executable programs including a software user interface 32 (such as a graphical user interface) and a rule execution engine 34, which produces system construction commands 36. The executable programs stored in the memory module 24 also include a tool controller 38, compilers 40, and linkers 42. The tool controller 38 receives the system construction commands 36 and existing program files 44. The tool controller 38 operates in conjunction with the compilers 40 and linkers 42 to execute the system construction commands 36 on the existing program files 44 to yield an updated executable program 46.

The processing associated with prior art software system management devices is more fully appreciated with reference to FIG. 2. The input data to the apparatus is a rule-based software configuration description 30, such as provided by MAKE.RTM.. The software user interface 32 receives this information and passes it to a rule execution engine 34, which produces a set of system construction commands 36. For instance, if the rule-based software configuration description 30 specifies that files A, B, and C are to be combined to form file D, then the system construction commands 36 would constitute a set of commands that could be executed by the tool controller 38 to compile and link existing files A, B, and C to form file D.

Thus, the tool controller 38 executes the system construction commands 36 by interacting with the compilers 40, linkers 42, and existing program files 44. After the tool controller 38 has executed the system construction commands 36, an updated executable program 46 is produced.

Some software system management tools, such as CAPITL (Computer Aided Programming In The Large; developed at the University of Wisconsin), rely upon first-order logic. First-order logic refers to first-order predicate calculus wherein facts may be expressed as a combination of a functor and an argument. For example, in the statement "dog(fido)", the term "dog" is a functor, while "fido" is an argument. Thus, a functor may be thought of as a general truth, while an argument is an instance of the general truth. In first-order predicate calculus, functors are constant, that is, a functor's value cannot change.

First-order logic is used to express relations between elements. For example, the statement "conn(X,Z) :- conn(X,Y) & conn(y,z)" indicates that there is a connection between X and Z if there is a connection between X and Y and between Y and Z. Thus, it can be appreciated that first-order logic may be used in software system management to express relations between different files. For example, first-order logic may be used to express a fact that one file must be compiled before a second file is compiled.

Some system modellers, such as MAKE.RTM., do not use first-order logic, they use ad hoc rules. Ad hoc rules are less powerful than first-order logic. For example, using cad hoc rules, a transformation from A into B into C must be explicitly defined as a two step transformation A.fwdarw.B & .fwdarw.B.fwdarw.C. Ad hoc rules expressed in procedural statements of this type cannot automatically deduce the rules necessary to transform A into C. Therefore, existing software system management tools, such as MAKE.RTM., require a programmer to produce a set of ad hoc rules that are used to explicitly define software elements, their interdependencies, and the rules required to construct an executable file.

It would be highly desirable to provide a software system management tool that automatically assesses file dependencies and executes file handling rules. Such a system would allow a user to merely specify a desired property for a file to be formed. Thereafter, the software system management tool would execute all of the logic to achieve the desired result. Specifically, the software system management tool would generate and run the necessary commands to produce the desired file.

Automatic assessment of file dependencies and execution of file handling rules can, in theory, be realized using second-order logic. As indicated above, in first-order logic, functors are constant. In second-order logic, functors can be variable. That is, a functor variable can represent any one of a number of functor constants. Thus, in the statement "A(X,Y)". The functor variable "A" is not limited to being a "dog", as in the first-order logic example above, it can also be a "cat", "horse", etc. Second-order logic can be defined as generalized logic, based upon first-order logic, that allows logical deductions to be made from arbitrary facts, relations, or rules. Thus, in the context of software system management, a second-order system would provide a mechanism for making logical deductions from arbitrary files, file relations, and file handling rules.

Second-order logic has not been applied to software system management in the past because it is computationally expensive. Since a variable functor could be any of an infinite number of arbitrary relations, the resultant search space is prohibitive. Limited second-order logic can be applied to software system management if the functors are confined (bounded) to a set of user-defined predicates. However, this can still be an inherently limited approach. Moreover, without explicit separation of the import and export predicates, errors (e.g., in a second-order logic system description) can only be identified at execution time, not at compile time.

Thus, it would be highly desirable to provide a software modelling system that utilizes unbounded second-order logic, but does not have the execution penalties typically associated with unbounded second-order logic. Such a system would automatically define relations between files and generate commands to achieve a final product. Therefore, the user would not be forced to define all the relations between the files and the rules required to achieve a final product.

It would also be desirable to provide a software modelling system that can identify system errors at compile time. In particular, it would be desirable to provide a compile-time scope analysis. As understood in the art, scope is a rigorous framework of program code that limits the global visibility of program parts. Scoped information is only externally visible if it is explicitly exported by a defining module, and explicitly imported by the using module. Scoped information can only be imported into a module if it is exported by another module that it can see.

The following is a glossary of terms that will be used in the Detailed Description of the Invention.

Atom: An indivisible word or number, such as "dog" or "3". Words must begin with lower case letters.

Variable: An alphanumeric string that begins with an uppercase letter and can assume various values.

Term: A syntactic unit, either a simple atom, or a compound term, such as "dog(fido, brown)".

List: A set of terms enclosed within square brackets, e.g."[a, b, c]".

Functor: The head part of a compound term. For example, the functor of"dog(fido)" is "dog". In second-order logic, functors can be variables, for example "V(X, dog)". Functors define a general truth.

Arguments: The terms inside the parenthesis of a compound term, for example the arguments of"a(p(q),C)" are "p(q)" and "C". Arguments are parameters associated with a functor.

Ground: A ground term contains no variables. A ground functor is an atom, not a variable.

Rule: A logical statement of the form "X is true if Y and Z are true". It is written "X.rarw.Y & Z". The first part, X, is called the head. The remainder, Y & Z, is known as the body. Each term in the body is known as a subgoal.

SUMMARY OF THE INVENTION

A software system manager to achieve second-order logical management of a software system model is described. The system relies upon a second-order logic system description that uses variable functors with specified import predicate arguments and export predicate arguments. The second-order logical system description includes a second-order system model, a second-order rule set, and a second-order operation module. The second-order system model defines a set of existing program files, the second-order rule set defines a set of operations that can be performed on the existing program files, and the second-order operation module specifies an operation to be executed by the second-order rule set on the set of existing program files. The second-order logic system description is used to generate a set of system construction commands. The system construction commands specify the commands necessary to transform the existing program files into intermediate object files that are used to produce an executable program.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the nature and objects of the invention, reference should be made to the following detailed description taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a prior art software system management apparatus that executes a rule-based description of a software model. FIG. 2. illustrates the processing associated with the prior art software system management apparatus of FIG. 1.

FIG. 3 is a software system management apparatus, in accordance with the invention, using second-order logic,

FIG. 4 illustrates the processing associated with the software system management apparatus of FIG. 3.

FIG. 5 illustrates the data structure for the second-order system model of the invention.

FIG. 6 illustrates the data structure for the second-order rule set of the invention.

FIG. 7 illustrates an example second-order system query to be executed in accordance with the invention.

FIG. 8 is a file relation graph corresponding to an example system operation described below. FIG.9 illustrates the first-order logic data structure that is used to express the second-order system model of the invention. FIG. 10 depicts the relations between files derived in accordance with an example illustrating the present invention.

Like reference numerals refer to corresponding parts throughout the several views of the drawings.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 3 illustrates the software system management apparatus 50 of the present invention. Several elements associated with the apparatus 50 are the same as those of the prior art apparatus 20 illustrated in FIG. 1. These elements are identified with identical reference numbers. The apparatus of FIG. 3 is unique in the following respects. First, a second-order logic system description 54 is entered by a user at the hardware user interface 26. The hardware user interface 26 runs a software user interface 52, as will be discussed below, that supports the second-order logic system description 54. The second-order logic system description 54 is downloaded into memory 57. Memory 57 also includes the following novel elements: a second-order system model 56, second-order operation modules 58, a second-order inference structure 60, a transformation engine 62, a reduced first-order system model 64, and a query engine 66.

The operation of the apparatus of FIG. 3 is illustrated in FIG. 4. A second-order system model 56 is supplied to a software user interface 52. The second-order system model is a second-order description of fifes and their interdependencies. The software user interface 52 supports second-order operation modules 58 by displaying these modules on the hardware user interface 26. The second-order operation modules 58 define different types of operations that can be performed on a software system. Example operations include showing the dependencies between files, exhibiting different file versions, and making necessary compilations to execute a system model. Preferably, each operation has a corresponding icon that can be selected. The software interface 52 interacts with a second-order inference structure 60, which is a second-order rule set that defines the actions that are necessary to achieve the operations defined in the second-order operation modules 58.

In sum, when the data processing of the invention commences there are three discrete elements associated with the second-order logic system description 54. Specifically, there is the second-order system model 56, the second-order operation modules 58, and the second-order inference structure 60.

Note that prior art rule-based software configuration descriptions constitute an integrated description of the files, file interdependencies, and rules to generate system information or an updated program. Note also that in the prior art rule-based software configuration system, the user is required to generate the complete description of the files, file interdependencies, and rules. In contrast, the user of the present invention only has to select a second-order operation module 58 and invoke a second-order system model 56. The second-order system model 56 may be keyed in at the user interface 26 or it may be obtained from the system 50 itself. That is, the existing program files 44 of the system 50 may simply be displayed on the hardware user interface 26 that is running the software user interface 52 and then selected to form the second-order system model 56.

The second-order logic system description 54 of the invention is applied to a query engine 66. The query engine 66 uses the second-order inference structure 60 to run the second-order operation modules 58 on the second-order system model 56. This operation produces a set of system construction commands 68. As with the apparatus of FIG. 1, the system construction commands 68 are executed by the tool controller 38, which interacts with the compilers 40, the linkers 42, and the existing program files 44, to produce an updated executable program 46.

While the second-order logic system description 54 may be directly interpreted by a query engine 66, it is preferable to convert the second-order logic system description 54 into intermediate code for execution on a query engine in the form of a relational engine. Such an operation is described in Geoffrey Phipps, Glue: A Deductive Database Programming Language, Ph.D. thesis, Stanford University, Stanford, Calif., 1992. Department of Computer Science Report No. STAN-CS-92-1460, and Marcia A. Derr, Adaptive Optimization In A Database Programming Language, Ph.D. thesis, Stanford University, Stanford, Calif., 1992. Department of Computer Science Report No. STAN-CS-92-1460. In addition, the second-order logic system description 54 may be transformed into a textual first-order description which is then interpreted by the query engine 66. In one embodiment of the invention described below, the second-order logic system description 54 is transformed into the textual first-order description widely known as PROLOG. Thereafter, the first-order description is applied to a standard PROLOG interpreter. Thus, FIG. 4 illustrates that the second-order logic system description may be passed to a transformation engine 62 that produces a first-order logic system description 64, which includes a first-order system model, system queries, and a rule set.

The foregoing overview of the invention as described in relation to FIG. 4 generally illustrates that the process of the invention entails using a second-order logic system description to achieve software system management. The system of the invention replaces ad hoc rule systems, associated with first-order logic, with a second-order logic system that allows logical deductions to be made from arbitrary files, file relations, and file handling rules. It can be appreciated that instead of providing a rule-based description of the software configuration, the user of the system only needs to specify a second-order system model and then select a second-order operation to achieve a useful result, such as an updated executable program 46. The second-order inference structure 60 of the invention operates transparently to the user to perform the operations that are normally specifically specified by a user through a rule-based description.

Attention is presently directed toward the features of the invention that facilitate the second-order logic software system management apparatus and method of the invention. Thereafter, attention turns to specific implementations of the invention.

As indicated in the background section, with second-order logic, functors are variable. The present invention has variable functors. However, to provide a limited search space, import predicate arguments and export predicate arguments for each variable functor are specifically declared. Thus, the second-order system model 56 includes specifically declared import predicate arguments and export predicate arguments. Similarly, the second-order inference structure 60 includes a set of rules that operate on import predicate arguments and produce export predicate arguments. In addition, the second-order operation modules 58 use variable functors with import predicate arguments and export predicate arguments to specify desired software system management functions. Thus, the software system management method of the invention utilizes scope. That is, scoped information within the system is only externally visible to the entire system if the information is explicitly exported by a defining module and explicitly imported by a using module. The scoped information of the invention allows a compile time analysis of the defined second-order logic system description. That is, by simply checking the declared import predicate arguments and export predicate arguments, errors can be identified at compile time.

The specified import predicate arguments and export predicate arguments of the invention enable a second-order logic software system management method. Consequently, a rule-based procedural description of the software configuration is not required. That is, the second-order logic allows generalized logical deductions to be made based simply upon the second-order system model 56. These concepts are more fully appreciated with references to the specific embodiments of the invention described below.

FIG. 5 illustrates a data structure for the second-order system model 56 of the invention. The system model includes declared import predicate arguments that are separated by a colon from declared export predicate arguments. The body of the module includes a first set of file statements that declare files 1 through N. The body also declares a set of "refer.sub.-- to" facts that express relationships between files. The "from" file has a reference to the "to" file.

FIG. 6 illustrates a data structure for the second-order inference structure 60 of the invention. The rule set includes declared import predicate arguments that are separated by a colon from declared export predicate arguments. The body of the module includes rules 1 through N. The import predicate arguments are applied to the rules to produce export predicate arguments.

FIG. 7 illustrates an example of a second-order operation module 58 of the invention. The operation modules of the invention may be thought of as queries that result in system operations. The modules specify a query. The answer to the query is a desired property for a file. The second-order system model 56 describes the available files and the second-order inference structure 60 establishes the operations that may be used to obtain the desired file. In the example of FIG. 7, the system model is declared, the rule set is declared, a predicate variable is declared, and a built-in predicate is called. The predicate variable is simply a variable and the built-in predicate is an operation native to the environment. Built-in predicates are simple logical operations, such as "=" and "!=" (not equal).

The generalized data structures shown in FIGS. 5 through 7 are more fully appreciated with reference to specific examples. The following code is an example of a second-order system model.

    ______________________________________
    (1)     module system.sub.-- model( :file, refers.sub.-- to ) {
    (2)       file( t1 ).
    (3)       file( t2 ).
    (4)       file( t3 ).
    (5)       file( t4 ).
    (6)       file( t5 ).
    (7)       refers.sub.-- to( t1, t2 ).
    (8)       refers.sub.-- to( t2, t4 ).
    (9)       refers.sub.-- to (t4 ,t4 ).
    (10)      refers.sub.-- to( t1, t3 ).
    (11)      refers.sub.-- to( t3, t4 ).
    (12)      refers.sub.-- to( t3, t5 ). }
    ______________________________________

    ______________________________________
    (13)    module rule.sub.-- set( node, edge:path ) {
    (14)      path( X, X ) <- node( X ).
    (15)      path( X, Z ) <- edge( X, Y ) & path( Y, Z ). }
    ______________________________________

    ______________________________________
    (16) module system.sub.-- model( :F, I ) &
    (17) module rule.sub.-- set( F, I:Uses ) &
    (18) Uses( X, Y ) &
    (19) X != Y
    ______________________________________

    ______________________________________
    (20) tr( Module.sub.-- name, Import.sub.-- args, Export.sub.-- predicates,
         Internal.sub.-- predicates, Functor, Args )
    ______________________________________

    ______________________________________
    (30) tr( system.sub.-- model, [ ], [file,refers.sub.-- to], [ ],
        file, [t1] ).
    (31) tr( system.sub.-- model, [ ], [file,refers.sub.-- to], [ ],
        file, [t2] ).
    (32) tr( system.sub.-- model, [ ], [file,refers.sub.-- to], [ ],
        file, [t3] ).
    (33) tr( system.sub.-- model, [ ], [file,refers.sub.-- to], [ ],
        file, [t4] ).
    (34) tr( system.sub.-- model, [ ], [file,refers.sub.-- to), [ ],
        file, [t5] ).
    (35) tr( system.sub.-- model, [ ], [file,refers.sub.-- to], [ ].
                         refers.sub.-- to, [tl,t2] ).
    (36) tr( system.sub.-- model, [ ], [file,refers.sub.-- to], [ ],
                         refers.sub.-- to, [t1,t3] ).
    (37) tr( system.sub.-- model, [ ], [file,refers.sub.-- to] [ ],
                         refers.sub.-- to [t2,t4] ).
    (38) tr( system.sub.-- model, [ ], [file,refers.sub.-- to], [ ],
                         refers.sub.-- to, [t3,t4] ).
    (39) tr( system.sub.-- model, [ ], [file,refers.sub.-- to], [ ],
                         refers.sub.-- to, [t4,t4] ).
    (40) tr( system.sub.-- model, [ ], [file,refers.sub.-- to], [ ],
                         refers.sub.-- to, [t3,t5] ).
    ______________________________________

    ______________________________________
    (41) import( Module, Import.sub.-- args, Exports, Local,
               Functor )
    ______________________________________

    ______________________________________
    (50)   tr( rule.sub.-- set,
    (51)     [import( DNm, DNi, DNe, DN1, Node ),
    (52)      import( DEm, DEi, DEe, Del, Edge ) ],
    (53)      [path], [ ], path, [X,X]
    (54)   ) :-
    (55)   tr( DNm, DNi, DNe, DN1, Node, [X] ).
    (56)   tr( rule.sub.-- set,
    (57)     [import( DNm, DNi, DNe, DN1, Node),
    (58)      import( DEm, DEi, DEe, DE1, Edge)],
    (59)      [path], [ ],path,[X,Z],
    (60)   ) :-
    (61)   tr( DEm, DEi, DEe, DE1, Edge, [X,Y] ),
    (62)   tr( rule.sub.-- set[import( DNm, DNi, DNe, DN1, Node ),
    (63)     import( DEm, DEi, DEe, DE1, Edge ) ],
    (64)     [path], [ ], path, [Y,Z]).
    ______________________________________

    ______________________________________
    (70)   tr( rule.sub.-- set,
    (71)     [import( system.sub.-- model, [ ], [F,I], [ ], F),
    (72)      import( system.sub.-- model, [ ], [F,I] ,[ ], I)],
    (73)     [Uses], [ ], Uses, [X,Y]),
    (74)   X != Y.
    ______________________________________

    ______________________________________
    (75)   tr( rule.sub.-- set,
    (76)     [import( system.sub.-- model, [ ], [file,refers.sub.-- to],
    (77)            [ ], file ),
    (78)     import( system.sub.-- model, [ ], [file,refers.sub.-- to],
    (79)            [ ], refers.sub.-- to ) ],
    (80)     [path], [ ], path, [X,X]
    (81)   ) :-
    (82)   tr( system.sub.-- model, [ ], [file, refers.sub.-- to], [ ],
    (83)            file, [X] ).
    ______________________________________

    ______________________________________
    (84)             X     Y
    (85)             t1    t2
    (86)             t1    t4
    (87)             t1    t3
    (88)             t1    t5
    (89)             t2    t4
    (90)             t3    t5
    (91)             t3    t4
    ______________________________________

    ______________________________________
           (100)module src( : is, date ) {
           (101) is( `cli.c`, c.sub.-- file ).
           (102) date( `cli.c`, 732486691 ).
           (103) is( `Unix.h`, h.sub.-- file ).
           (104) date( `Unix.h`, 732487804 ).
           (105) is( `Unix c`, c.sub.-- file ).
           (106) date( `Unix.c`, 732326484 ).
           (107) is( `aa.y`, yacc.sub.-- file ).
           (108) date( `aa.y`, 732320091 ).
           (109) is( `aa.h`, h.sub.-- file ).
           (110) date( `aa.h`, 732475330 ).
           (111) is( `bb.1`, lexfile ).
           (112) date( `bb.1`, 731877729 ).
           (113) is( `cli.o`, o.sub.-- file ).
           (114) date( `cli.o`, 732487744 ) . }
    ______________________________________

    ______________________________________
    (120)module environment( : env, env.sub.-- control ) {
    (121)    env( cc, `/bin/acc` ).
    (122)    env( cflags, `-Xs -g` ).
    (123)    env( ld.sub.-- flags, `-lce -ldl` ).
    (124)    env( target.sub.-- name, cli ).
    (125)    env.sub.-- control( cc, override ).
    (126)    env.sub.-- control( cflags, override ).
    (127)    env.sub.-- control( ld.sub.-- flags, union ).
    (128)    env.sub.-- control( target.sub.-- name, override ) .
    ______________________________________
             }

    ______________________________________
    (150)module stdc( env.sub.-- in, env.sub.-- control, is.sub.-- in,
    date.sub.-- in:
    (151)   is, date, derivation, set ) {
    (152) env( Name, Value )<-
    (153)   env.sub.-- control( Name, Union ) &
    (154)   (env.sub.-- in( Name, Value ) .linevert split.
             env.sub.-- local( Name, Value ) ).
    (155) env( Name, Value )<-
    (156)   env.sub.-- control( Name, local ) &
    (157)   env.sub.-- local( Name, Value ).
    (158) env( Name, Value )<-
    (159)   env.sub.-- control( Name, override ) &
    (160)   env.sub.-- in( Name, Value ).
    (161) is( Name, Type )<-
    (162)   is.sub.-- in( Name, Type ).
    (163) env.sub.-- local( ld.sub.-- flags, `-ly` )<-
    (164)   is( .sub.--, yacc.sub.-- file ).
    (165) env.sub.-- local( ld.sub.-- flags, `-1l` )<-
    (166)   is( .sub.--, lex.sub.-- file ).
    (167) date( Name, Date )<-
    (168)   date.sub.-- in( Name, Date ).
    (169) date( Name, O ) <-
    (170)   derived ( Name ) &
    (171)   !date.sub.-- in( Name , .sub.--  ).
    (172) derived( Name )<-
    (173)   is( Name, o.sub.-- file ).
    (174) derived( Name )<-
    (175)   is( Name, bin.sub.-- file ).
    (176) derived( `y.tab.c` )<-
    (177)   is( `y.tab.c`, c.sub.-- file ).
    (178) derived( `lex.yy.c` )<-
    (179)   is ( `lex.yy.c`, c.sub.-- file ).
    (180) is( Bin, bin.sub.-- file )<-
    (181)   env( target.sub.-- name, Bin ) &
    (182)   derivation( narrow, ogroup, Bin, .sub.--  ).
    (183) derivation( narrow, ogroup, Bin, Command)<-
    (184)   set( ogroup, O ) &
    (185)   OO=O // ` ` &
    (186)   env( target.sub.-- name, Bin ) &
    (187)   env( ld.sub.-- flags, Flags ) &
    (188)   FF=Flags // ` ` &
    (189)   groupby( Bin ) &
    (190)   Command= `ld -o` // Bin // ` `
              // concatenate(FF).
    (191) set( ogroup, o )<-
    (192)   is( O, o.sub.-- file ).
    (193) is( O, o.sub.-- file )<-
    (194)   is( C, c.sub.-- file )&
    (195)   change.sub.-- extension( C, `.c`, O, `.o,` ) &
    (196)   derivation( straight, C, O, .sub.--, .sub.--  ).
    (197) %compiling c.sub.-- files to o.sub.-- files.
    (198) derivation( straight, C, O, Command )<-
    (199)   is( C, c.sub.-- file )&
    (200)   change.sub.-- extension( C, `.c`, O, `.o` ) &
    (201)   env( cc, CC ) &
    (202)   env( cflags, F )&
    (203)   FF=` ` // F // ` ` &
    (204)   groupby( C ) &
    (205)   Command=
    (206)   CC // `-o` // O // `-c sun4` //
              concatenate (FF) // C.
    (207) %yacc rules
    (208) derivation( widen, Yacc, yacc.sub.-- group,
               Command ) <-
    (209)   is( Yacc, yacc.sub.-- file )&
    (210)   Command=`yacc `//Yacc.
    (211) is( `y.tab.c`, c.sub.-- file )<-
    (212)   is( .sub.--, yacc.sub.-- file ).
    (213) is( `y.tab.h`, h.sub.-- file )<-
    (214)   is( .sub.--, yacc.sub.-- file ).
    (215) set( yacc.sub.-- group, `y.tab.c` ).
    (216) set( yacc.sub.-- group, `y.tab.h` ).
    (217) is( `lex.yy.c`, c.sub.-- file )<-
    (218)   is( .sub.--, lex.sub.-- file ).
    (219) derivation( straight, Lex, `lex.yy.c`,
              Command )<-
    (220)   is( Lex, lex.sub.-- file )&
    (221)   Command=`lex ` // Lex.
    (222) change.sub.-- extension( From, F.sub.-- ext, To, T.sub.-- ext )<-
    (223)   From=Stem // F.sub.-- ext &
    (224)   To=Stem // T.sub.-- ext. }
    ______________________________________

    ______________________________________
    (250)    module src( :Inputs, Dates ) &
    (251)    module environment(:Env, Envc ) &
    (252)    module stdc( Env, Envc, Inputs, Dates:
    (253)        Created, .sub.--, Derivation, .sub.--) &
    (254)      Created( New.sub.-- name, .sub.--  ) &
    (255)      Derivation( .sub.--, .sub.--, New.sub.-- name, Command
    ______________________________________
             ).

    ______________________________________
    Name        Command
    ______________________________________
    (270)cli.o  /bin/acc -o cli.o -c sun4 -Xs -g cli.c
    (271)Unix.o /bin/acc -o cli.o -c sun4 -Xs -g Unix.c
    (272)y.tab.c
                yacc aa.y
    (273)y.tab.h
                yacc aa.y
    (274)y.tab.o
                /bin/acc -o cli.o -c sun4 -Xs -g y.tab.c
    (275)lex.yy.c
                lex bb.l
    (276)lex.yy.o
                /bin/acc -o cli.o c sun4 -Xs -g lex.yy.c
    (277)cli    ld -o cli cli.o Unix.o y.tab.o lex.yy.o
    lce -ldl -ll -ly
    ______________________________________

• Inventors
  Phipps, Geoffrey R.;
• Assignee
  Sun Microsystems, Inc. (Mountain View, CA)
• Published
  Jun-17-1997
• Current US Classes:
  706/45
  706/922
  717/104
  717/121
• Application #
  246111
• International Classes
  G06F 017/00
• Field of Search
  395/700 395/500 395/55 395/650 395/703 395/701 395/702 364/419.08
• Examiner
  Kriess; Kevin A.
• Agent
  Flehr Hohbach Test Albritton & Herbert LLP, Galliani; William S.
• US Patent References:
  5159687
  5257363
  5274820
  5274821
  5276775
  5321606