mark@hpcllmr.HP.COM (Mark Rozhin) (02/04/89)
hp pascal handles it the following way: when a module is compiled, it's interface (export part) is written somewhere. by default, it is written to a special spot in the object file. optionally, it can be written to a 'module library'. we don't much like this second mechanism, cause now you have two files to worry about instead of one. when importing, the user can tell the compiler where to look for the module interface stuff (either an object or archive (come to think of it, an executable library should work too), or a module library). if the stuff is not found there, the compiler looks in a standard place for module stuff. (i've forgotten where it is.) the drawback of the whole thing is that you encode information about where to find module interfaces right in the source. what if you move source? what if you have a big piece of software and you swap versions of different module? an environment sounds nice. modules just float about in some hyperspace and the compiler & development system suck them out. m
corbett@beatnix.UUCP (Bob Corbett) (02/15/89)
In an earlier posting, I described a scheme for implementing
separate compilation for Extended Pascal. My proposal was based on
having the compiler maintain catalogue files. Catalogue files
would contain the names of files submitted to and created by the
compiler. The response to my proposal has been overwhelmingly negative.
I am now formulating new proposals for separate compilation.
Few of the people who have written or spoken to me have read the
proposed standard. Most of the schemes that have been offered in
opposition to my proposals violate the proposed standard. If anyone
feels that he or she knows the right way to implement separate
compilation, he or she should let the standards committee know about it.
Otherwise, he or she is likely to find that his or her method is
prohibited by the new standard.
I am exploring a way of making separate compilation for Extended
Pascal look as much as possible like separate compilation for languages
such as C and Fortran. Under this scheme, each source file consists of
zero or more program components (a program component is either a
module-declaration or a main-program-declaration). When a source file is
compiled, the compiler will produce an object file. The object file will
contain an abstract syntax tree (AST) for each program component in the
source file. Semantic information will be maintained separately. Both
source and object files may be submitted to the compiler. If one of the
files contains a main- program-declaration and all names referenced
directly or indirectly from the main program can be resolved, an executable
file will be generated.
A drawback of this scheme is that it is impossible complete semantic
checking until link time. When a program component that imports an
interface is compiled, the compiler does not have access to the declarations
of the imported names unless the module declaration containing the interface
is contained in the source file. The compiler may not even know which names
have been imported. I fear that users will be upset when they get what
appear to be compilation errors at link time.
The problem can be avoided by requiring each source file to be compiled
in sequence and having the resulting object file retain information
about previously compiled files. Suppose a programmer is writing a linear
algebra program. He might write a source file main.p containing his main
program. The main program might import an interface dgemat contained in a
module in a file named linpack.p. The module containing the declaration
of the interface dgemat may itself import an interface named dblas1 contained
in a file named blas.p. Then the programmer could compile his program using
the command
pascal blas.p linpack.p main.p
Assuming all references could be resolved, the compiler would produce an
executable file named a.out. If some references could not be resolved, it
would produce a file main.o, which would contain compiled code for blas.p,
linpack.p, and main.p. If the programmmer wished use separate compilation,
he could first use the command
pascal blas.p
to produce an object file blas.o. Next he could use the command
pascal blas.o linpack.p
to produce an object file for blas.p and linpack.p. Finally, he could
complete the compilation with the command
pascal linpack.o main.p.
However, he could not compile linpack.p without blas.o or blas.p, and he
could not compile main.p without linpack.o or linpack.p. This approach
eliminates the need to store abstract syntax trees, since code can be
generated at each stage of compilation.
I welcome comments and suggestions regarding separate compilation
for Extended Pascal in general or my scheme in particular.
Yours truly,
Bob Corbettcorbett@beatnix.UUCP (Bob Corbett) (02/18/89)
Even though this message, deals with Pascal, I am crossposting it to comp.lang.modula2, since Modula users may have useful experience concerning the matters under consideration. For the past two months, I have been trying to find a good way of implementing separate compilation for draft proposed American National Standard (dpANS) Extended Pascal. I hoped to find a better way than having the compiler maintain an interface file or module library. I have used such systems, and I did not find them pleasant to use. However, after posting a half dozen proposals and having them all shot down, I give up. The dpANS seems to prohibit any mechanism I like better than interface files or module libraries. There, I am resigned to using interface files. In my system, all interface files will be the named ".pascal". Whenever the compiler is invoked, it will read the interface information from the .pascal file in the current working directory before starting compilation. After a file has been successfully compiled, any interface information gleaned from it will be added to the interface file. If errors occur during compilation, the interface file will not be altered. Whenever a file whose filename component is the same as the filename component of a previously compiled file is compiled, the interface information from that previous compilation is deleted. (That last sentence reads like a sentence from the proposed standard.) I would appreciate suggestions regarding what an interface file should contain and how it should be formatted. I would also like to know what commands I should provide for manipulating interface files. I am currently planning to have the compiler read and process the entire interface file before starting compilation. I am assuming that interface files are usually small. If you have experience with a compiler that creates interface files, please let me know if my assumption is correct. Finally, if you knows a better way of implementing separate compilation for Extended Pascal, please send me a description of it. Yours truly Bob Corbett uunet!elxsi!corbett ucbvax!sun!elxsi!corbett