Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code

bart@cs.uoregon.edu (Barton Christopher Massey)
Thu, 14 Jan 1993 00:50:07 GMT

          From comp.compilers

Related articles
[4 earlier articles]
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code tmb@arolla.idiap.ch (1993-01-12)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code jlg@cochiti.lanl.gov (1993-01-12)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code drw@euclid.mit.edu (1993-01-12)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code wilson@ann-arbor.applicon.slb.com (1993-01-13)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code nickh@CS.CMU.EDU (1993-01-13)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code chased@rbbb.Eng.Sun.COM (1993-01-13)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code bart@cs.uoregon.edu (1993-01-14)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code rv@erix.ericsson.se (1993-01-14)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code smk@dcs.edinburgh.ac.uk (1993-01-14)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code tmb@arolla.idiap.ch (1993-01-15)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code ken@eies2.njit.edu (1993-01-16)
| List of all articles for this month |
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
--


Post a followup to this message

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