Re: Errors and Type checking.

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Tue, 12 Jan 1993 09:24:45 GMT

          From comp.compilers

Related articles
Compile Time vs. Run Time TDARCOS@MCIMAIL.COM (Paul Robinson) (1993-01-08)
Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code jlg@cochiti.lanl.gov (1993-01-11)
Errors and Type checking. winikoff@cs.mu.oz.au (1993-01-12)
Re: Errors and Type checking. anton@mips.complang.tuwien.ac.at (1993-01-12)
| List of all articles for this month |
Newsgroups: comp.compilers
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Tue, 12 Jan 1993 09:24:45 GMT
References: 93-01-041 93-01-065
Keywords: performance, debug

jlg@cochiti.lanl.gov (J. Giles) writes:
> Most errors are not syntactic or static semantic errors (like type
> errors). The vast majority of debugging time is spent isolating and
> correcting problems which are not - and cannot be - found by the
> typechecks no matter how strict your type system is.


I can confirm this from experience with languages that do not check types
at all (e.g. Forth). I have not found type errors to be a problem. There
are two reasons for this:


1) I make fewer type errors than when programming in a compile-time
type-checked language. I.e., I am more careful. It probably takes a bit of
time to develop that programming mode.


2) When I make a type error, it is usually easy to catch and correct (It
helps if the language is interactive).


I think the more problematic type errors are those that the type checker
does not check, e.g. a search tree that is not sorted. Of course, this
sort of error could be caught with compile-time assertion checkers, but
somehow this technology has not caught on.


- anton
--
M. Anton Ertl anton@mips.complang.tuwien.ac.at
--


Post a followup to this message

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