Re: Compilers 2000

Re: Compilers in the year 2000


Better optimization would of course be nice, but I think the real leverage
will come from more kinds of static analysis performed at compile-time.
Programmers should be able to augment their program by both global and
local assertions/constraints of various sorts, and the compiler should do
its best to identify all violations of these assertions/constraints at
compile-time. This should be true whether the compiler operates
incrementally, or in a batch mode.


I think we are still a long way from being able to feasibly prove a large
program to be "correct," but it is still extremely useful and instructive
to be able to establish program-wide statically-checkable constraints.
Having the compiler check these constraints can go a long way toward early
detection of errors.


An even more general approach is to have an entire sub-language for
compile-time analysis. It would be extremely powerful to be able to write
essentially an arbitrary amount of code which will be executed
(interpreted) at compile-time during the compiler's scanning of a program
tree. "Constraints" can then be seen as a special case of this,
corresponding to compile-time code which is the equivalent of: "if not
<boolean-expresion> then Report_Error."


Obviously compile-time code must only depend on and manipulate attributes
known at compile-time. This would generally include the value of
compile-time constants, the type of expressions, etc., but could be
generalized to arbitrary user-defined compile-time attributes.


S. Tucker Taft stt@inmet.inmet.com uunet!inmet!stt
Intermetrics, Inc.
Cambridge, MA 02138
--

Return to the comp.compilers page.
Search the comp.compilers archives again.