LIBRARY construct (was: A possible new port)

[Brian Hawley <bhawley@luc.edu>]

To recap...

Brian Hawley wrote:
>Would anyone be interested if I proposed a LIBRARY construct? It would
>allow global optimizations to be performed on groups of modules that
>would be put together into one .Obj file with one .Sym file. This would
>be useful for the Oberon System, where there are no standalone
>programs, and also for creating shared libraries on systems that
>support them, like Unix and Windows.

Michael van Acken replied:
>I don't support this as a language extension, but I wouldn't mind if
>an external tool would implement this.

Frank Copeland replied:
>I don't support language extensions in general, and it seems to me that
>something like this would require a major change to the Oberon System
>itself. Both the compiler and the loader expect one module per
>symbol|object file. Under AmigaOS creating a library is as simple as
>concatenating several object files and telling the linker to search the
>result instead of the individual object files. (Actually there are several
>kinds of 'library' constructs in AmigaOS and it can get confusing).

What I had in mind was something that would act like a makefile/library 
definition/project file. This would be a text file with a syntax that 
would be Oberon-like. I wouldn't consider it to be a language extension 
per se, more like the .DEF file for a Windows program or DLL. It would
list the modules that are to be compiled together, list the external code
that is to be linked in (if there isn't some way of doing alias modules),
and define a list of aliases of types, constants, variables (if allowed)
and procedures that are defined in its modules. The various aliases are
exported by the library as if they were defined in a module of that name
and are treated as such by other modules that import it. Modules that are
linked into a library are completely hidden; the library defines only one
external interface, although elements defined in that interface alias ones
defined in its collection of modules.

This construct would provide a higher level of abstraction than the module.
It would be especially useful with OSes like Windows and the Oberon System
that have executables with more than one entry point, or to define shared
libraries on other OSes. It would allow you to organize a set of modules in
the best way for your purposes but still show the cleanest interface to the
outside world, without sacrificing speed or flexibility to do it. You could
even have library templates to define standard system components (useful in
Windows programming). If you are using an IDE, it could even generate the
library definition file.

Conceptually, the output of a library would be like a single module that 
exports only what the library exports and hides the rest. With the Oberon
System that is exactly what the compiler would generate: one .Obj and one
.Sym (compatible with the native format), which would be seen externally 
as one module. Other OSes would output a library in the native style (dll, 
exe, .sa) and .Sym (and perhaps a .Obj stub) that serve as a module alias 
for OOC code. Inter-module (global) optimization would only be performed 
between modules that are linked together into a program or library (if 
there is a difference--there is none in Windows). The generated Oberon
code could be compiled into one piece or split into dozens in the same 
file, as appropriate for the native loader's purposes. Data resources 
could also be linked in on OSes that support that.

So what do you think?
Brian Hawley