|Compilers 2000 firstname.lastname@example.org (Jeff Prothero) (1990-09-28)|
|Re: Compilers 2000 email@example.com (1990-10-02)|
|Re: Compilers 2000 firstname.lastname@example.org (1990-10-06)|
|Re: Compilers 2000 email@example.com (1990-10-07)|
|From:||firstname.lastname@example.org (Tucker Taft)|
|Date:||Sun, 7 Oct 90 11:55:19 EDT|
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 email@example.com uunet!inmet!stt
Cambridge, MA 02138
Return to the
Search the comp.compilers archives again.