Newsgroups: | comp.compilers |
From: | bart@cs.uoregon.edu (Barton Christopher Massey) |
Organization: | University of Oregon Computer and Information Sciences Dept. |
Date: | Thu, 14 Jan 1993 00:50:07 GMT |
Keywords: | debug, design |
References: | 93-01-041 93-01-078 |
jlg@cochiti.lanl.gov (J. Giles) writes:
...
> The article I was responding to made claim that
> programs which pass the typechecker of a strictly typed language never
> have bugs (the exact statement was " An SML program which successfully
> typechecks will not bomb at runtime").
Note that "bombing", in modern vernacular, is different from "having a
bug" -- the former implies that the entire application crashes in some
dramatic way, whereas the latter merely implies that the application
doesn't behave in the desired fashion. It is true that a typechecked SML
program (compiled with a correct compiler :-) cannot do certain things,
like scribble on its own code or dereference a misaligned pointer, which
most programmers usually want to rule out because of their normally
disastrous consequences.
> [...] those remaining [deep semantic] bugs are the hardest to
> find and correct: they account for the vast majority of debugging time.
I think this is more an argument for language restriction than against it.
To take an extreme case, a missing semicolon may be a "syntactic" bug,
which merely causes the compiler to exit prematurely giving an informative
message, and is thus easy to correct. If the missing semicolon instead
causes the compiled code to behave in some strange and unexpected fashion,
then it's a "semantic" bug, which is hard to find and correct. To get rid
of the syntactic constraint often just moves all the cases that were
formerly in the first category to the second, increasing debugging time
drastically.
> In fact, I would be surprised if SML were so restrictive as to guarantee
> bomb-free code once you pass the typechecker. To be a useful, a
> programming language must allow sufficient flexibility to the user for a
> wide variety of algorithms and applications to be legally encoded. This
> means that the language will also *inherently* be sufficiently flexible
> for the user to inadvertantly code unintended, but still legal programs.
> That is in the very nature of programming language design.
No. That is the nature of *general-purpose* programming language design.
Usually, the more general-purpose we try to make a programming language,
the less the compiler can help us keep programs written in the language
error free. IMHO, SML is a pretty good compromise between general-purpose
and safe, being apparently much more general purpose than Pascal (to pick
an example), while being at least as safe as Pascal (maybe safer -- I
don't believe any Pascal spec requires the compiler to check the tags on
variant records).
Bart Massey
bart@cs.uoregon.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.