|Compile Time vs. Run Time TDARCOS@MCIMAIL.COM (Paul Robinson) (1993-01-08)|
|The definition of *bomb* firstname.lastname@example.org (1993-01-15)|
|Re: The definition of *bomb* nickh@CS.CMU.EDU (1993-01-18)|
|Re: The definition of *bomb* email@example.com (Paul Havlak) (1993-01-18)|
|From:||Paul Havlak <firstname.lastname@example.org>|
|Organization:||Center for Research on Parallel Computation|
|Date:||Mon, 18 Jan 1993 18:40:28 GMT|
Not to belabor the definition of "bomb", but it seems to me that there
is a useful distinction between undefined behavior and other kinds of
unwanted program behavior. Neither is necessarily easier to find by hand.
Undefined behavior makes a program meaningless according to the
language standard. Most high-level languages have large realms of
undefined behavior, especially if they are portable; for example, type
mismatches, subscripts out of bounds, or nondeterministic parallel access.
Hidden undefined behavior means that the abstract model of the
language has been violated, and the mapping of errors to behavior can be
subtle and unpredictable.
Functional language implementations have the advantage of
automatically detecting many kinds of undefined behavior. For example,
type mismatches are detected at compile time in ML, at run time in most
Lisp dialects. Their users pay for this in more restrictive languages,
slower compilers and/or slower execution. They gain a robust abstract
As hardware get faster and more complicated, and software also more
complicated, languages that are robust in this sense will do increasingly
Paul Havlak Dept. of Computer Science
Graduate Student Rice University, Houston TX 77251-1892
PFC/ParaScope projects (713) 527-8101 x2738 email@example.com
Return to the
Search the comp.compilers archives again.