Xref: utzoo comp.lang.misc:2706 comp.misc:5371 Path: utzoo!mnetor!tmsoft!dptcdc!jarvis.csri.toronto.edu!turing.toronto.edu!holt From: holt@turing.toronto.edu (Ric Holt) Newsgroups: comp.lang.misc,comp.misc Subject: Re: Program Errors and developement environment Keywords: list of possible errors Message-ID: <89Mar4.101745est.4448@turing.toronto.edu> Date: 4 Mar 89 15:17:37 GMT References: <881@sceard.UUCP> <313@bnr-fos.UUCP> Organization: /usr/local/lib/organization Lines: 121 I think the following long question deserves to be clarified, as it mixes up several concepts that we as Computer Scientists should understand: *In article <313@bnr-fos.UUCP> schow@bnr-public.UUCP (Stanley Chow) writes: *>In article <881@sceard.UUCP> mrm@sceard.UUCP (M.R.Murphy) writes: *> [Mike Murphy tells us about a list of programming errors that he has *> kept over the last ten years and asks for additions. SC] *>> *>> 1) Is the argument count correct? *>> 2) Is the spelling correct? *>> 3) Is the argment type correct? *>> 4) Is the variable initialized correctly? *>> 5) Do "ends" match "do"s? *>> 6) Is the correct register used? *>> 7) Is a previous equate, using, or define in effect? *>> 8) Is the level of indirectness correct? *>> 9) Are the defaults correct? *>> 10) Is the array large enough to hold the data? *>> 11) Is the index out of range? *>> 12) Is reentrancy, reusability, refreshability preserved? *>> 13) Did you let something go by that you can't explain? Fix it now. *>> 14) Does the program have anything remotely to do with the requirement *>> for the program? *>> 15) Did you start to code before thinking? *>> 16) Did you read the manual? SYNTAX, SEMANTICS AND FAITHFUL EXECUTION Before going further, we should ask: What characterizes a language? We have to understand that a language defines a SYNTAX (what strings are considered to be programs) and a SEMANTICS (what do programs mean or do). A great deal of confusion arises from the fact that one of the most popular languages, C, has a muddled semantics (we're not sure what pointers can do and mean; we're not sure what variable numbers of parameters do and mean; etc). This muddle shouldn't detract us from the fact that languages such as Turing have exactly specified semantics (it is mathematically clear what every construct does, independent of any implementation). OK, with that behind us, we can ask: does the implementation really follow the semantics. Before you say "of course", ask questions like: what are the semantics of dangling pointers, overflows, out of range subscripts, etc. The concept of FAITHFUL EXECUTION is defined to mean: the implementation is required to follow the semantics exactly, or else to halt and notify the user of the failure. With the default checking enabled, Turing gives you faithful execution, stopping and giving you an error message if ever anything occurs that is outside of the language's explicit semantics. DIRT AND DANGER Now let's go on to DIRTY language features, which by definition have their meaning determined by underlying implementation details, such as what's in a particular register (as opposed to CLEAN features, which are mathematically defined). Dirty features can be DANGEROUS, meaning they can cause remote corruption (eg, emitting assembly language by user control can cause arbitrary corruption that the language implementation has have almost no control over). The Turing Plus language introduces dirty features, in a controlled fashion, because these are needed for certain applications. The problem with dirt and danger is they put a tremendous responsibility on the programer, which would otherwise be born by the language implementation. My guess is that C's degree of dirt and danger costs 50% in terms of programmer productivity compared with programming in a faithful language. SPECIFICATION, CORRECTNESS, STYLE AND METHODOLOGY Add to these the concepts of SPECIFICATION (what's a program supposed to do) and CORRECTION (does the program do it) and STYLE (can you easily read the program and figure out how the program does it). METHODOLOLGY means do you know how to get from a specification to a correct program. In languages that are generally like Turing (Ada, Modula, Pascal, maybe C, etc) we have: SYNTAX - enforced by compiler SEMANTICS - produced by compiler and runtime support FAITHFULNESS - enforced by generated code and runtime support (depending on language) STYLE - depends on skill and patience of programmer CORRECTNESS - depends on programmer and methodology used Now, the questions are categorized using these concepts: 1) Is the argument count correct? SYNTAX 2) Is the spelling correct? SYNTAX 3) Is the argment type correct? SYNTAX 4) Is the variable initialized correctly? FAITHFUL, CORRECTNESS 5) Do "ends" match "do"s? SYNTAX 6) Is the correct register used? DIRTY 7) Is a previous equate, using, or define in effect? SEMANTICS (DIRTY?) 8) Is the level of indirectness correct? SEMANTICS, FAITHFUL 9) Are the defaults correct? SEMANTICS, FAITHFUL, CORRECTNESS 10) Is the array large enough to hold the data? FAITHFUL, CORRECTNESS 11) Is the index out of range? FAITHFUL, CORRECTNESS 12) Is reentrancy, reusability, refreshability preserved? SEMANTICS etc 13) Did you let something go by that you can't explain? Fix it now. CORRECTNESS, though language design helps tremendously to avoid shoot-in-the- foot-features. 14) Does the program have anything remotely to do with the requirement for the program? CORRECTNESS 15) Did you start to code before thinking? METHODOLOGY 16) Did you read the manual? METHODOLGY The above categorization of questions shows how the corresponding questions are handled in Turing-like languages. HOW DOES A LANGUAGE HELP? A language designed for productivity and reliability maximizes the degree to which problems are eliminated or detected by the computer, as opposed to by raw programmer acumen. As the language becomes less faithful and "dirtier" (Turing to Pascal to Turing Plus to C to assembler) you sacrifice productivity and reliability (as a rule). Similarly, as the language becomes more interpretive and dynamic in nature (Turing to Basic to APL to LISP) you get less syntactic help from the computer, as restrictions designed to help you are put off to run time or eliminated altogether. Ric Holt