paster@agaton.lu.se (Christian Collberg Magnus Krampell) (01/07/87)
This is in reference to earlier discussions over the net on inline expansion
and hidden types in Modula-2 and related languages.
We are currently working on a project in which we develop a translating
system for modular languages which enables the following language features:
(We're assuming a module-concept similar to the ones found in Ada, Mesa, and
Modula-2. A module consists of two parts: a specification describing the
objects exported from the module and an implementation implementing these
objects. Specifications and implementations are always separately compiled.)
1) Arbitrary-sized hidden types.
(i.e. in the specification part of a module no information
about the structure of a type T needs to be revealed:
TYPE T;
and in the implementation part T may be implemented as
any type allowed in the language, e.g.
TYPE T = RECORD
a, b : INTEGER
END;
Contrary to Mesa no garbage collection will be necessary.)
2) Hidden constants.
(i.e. in the specification part of a module the value of
a constant may be left out:
CONSTANT C : INTEGER;
and in the implementation part C may be given any value, e.g.
CONSTANT C : INTEGER = 314;
The type of C must be given in the specification in order to
ensure strong typechecking between modules.)
3) Inline expansion of procedures and CLU-style iterators.
(i.e. in the specification part of the module one may write
PROCEDURE P (a,b : INTEGER);
ITERATOR I (X : T1) : T2;
and in the implementation part one may specify that calls to
the subprogram should be substituted by its body:
INLINE PROCEDURE P (a,b : INTEGER);
BEGIN ... END P;
INLINE ITERATOR I (X : T1) : T2;
BEGIN ... END I;
This will work over module boundaries but not for recursive
procedures.)
4) Generic modules.
5) No dependencies between implementations.
(i.e. implementations can always be compiled in an arbitrary
order without compromising strong typechecking.)
The translating system will consist of two parts: a compiler and a paster.
The compiler will perform the tasks normally associated with compiler front-
ends, i.e. lexical, syntactic, and semantic analysis, but will only perform
partial optimization and code generation. It will produce low-level
intermediate code modules which are joined together by the paster. The paster
will thus take the place of the system linker which is used in most of today's
translating systems. The paster will perform the follwing tasks:
1) Evaluate constant expressions which could not be evaluated
during compilation. Such expressions will emerge whenever
a hidden type or constant is imported.
2) Fill in the results of the constant expression evaluation
in the code.
3) Expand procedure/iterator bodies inline.
4) Instantiate generic modules.
5) Optimize the intermediate code. The compiler will already
have optimized blocks of code which do not contain references
to imported hidden types and constants or imported procedures.
It will also have performed global data-flow analysis which
is made available to the paster.
6) Generate machine code from the intermediate representation.
This will already have been done for non-INLINE blocks
which do not contain references to imported hidden types
or imported procedures.
The above work will be presented at the 6th Annual IEEE Phoenix Conference
on Computers and Communication, Feb 25-27, 1987, in a paper titled "Design
and Implementation of Modular Languages Supporting Information Hiding".
Chris Collberg Magnus Krampell
Snail : Department of Computer Sciences
Lund University
BOX 118
S-221 00 Lund
Sweden
Email : {mcvax, seismo}enea!agaton!pandor!pasterjef@charming.uucp (Jef Poskanzer) (01/08/87)
In article <1119@agaton.lu.se> paster@agaton.UUCP (Christian Collberg Magnus Krampell) writes: [about a hundred lines on the ultimate modular language technology] Sounds great. I'm looking forward to reading more about this. One quibble, though: > Contrary to Mesa no garbage collection will be necessary.) Mesa does not have any garbage collection. Perhaps you were thinking of Cedar, Mesa's even less successful successor. --- Jef Jef Poskanzer unisoft!jef@ucbvax.Berkeley.Edu ...ucbvax!unisoft!jef (415)644-1230