Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!linus!philabs!seismo!harpo!ihnp4!fortune!phipps
From: phipps@fortune.UUCP (Clay Phipps)
Newsgroups: net.lang
Subject: Re: 'Lint' And Strong Typing - (nf)
Message-ID: <2296@fortune.UUCP>
Date: Tue, 17-Jan-84 19:25:28 EST
Article-I.D.: fortune.2296
Posted: Tue Jan 17 19:25:28 1984
Date-Received: Thu, 19-Jan-84 01:24:47 EST
References: <1376@pur-ee.UUCP>
Organization: Fortune Systems, Redwood City, CA
Lines: 85

------------------------------

In regard to the following comments:

    Could somebody tell me why a pre-processor couldn't be used 
    to flag type conflicts, rather than writing them into the language?  
    "Lint" is the obvious example, ...

For reasons that have nothing to do with human nature,
some type checking must be done by a compiler, rather than by a preprocesor,
to determine when widening or data conversions must be performed
by the emitted code, such as in the notorious case of

    int_var *= float_var

Therefore, you can't avoid them entirely.  In languages that are more-or-less
strongly typed, e.g., Pascal, the code already required by the language
definition to check type compatibility of subranges has the side effect
(or can, with a clean compiler design) of emitting the code to check 
whether array indices are within bounds (disabling this could be optional).
In my view, array bounds checking is best done by the compiler or hardware,
not by a preprocessor.

If you don't write the type-checking rules into the language definition,
you will have the problem of having source code that looks like C code
being rejected by one preprocessor but not another,
because each is checking for different things.
This will not have a positive effect on program portability.
Aren't there already enough problems with C compilers
that don't exactly conform to K&R (i.e., any of those based on the 
"Portable C Compiler"), without adding additional variation
in the selection of a preprocessor ?

And what about the poor "maintenance and enhancement" programmer,
who will have no clue from the source code about how stringently
(if at all) a C program was type-checked ?
After all, the UNIX custom seems to be for compilers not to produce
a listing that could tell a programmer what options were used 
for compilation or preprocessing, and there is no guarantee 
that such an important listing, even if produced, would be retained.

    ... if you want to be stern, 
    you could require that each line of code which fails "lint" 
    must be justified in writing, subject to somebody's approval. 

C'mon, now !  If a programmer is going to skip a simple procedure
like use of "lint" because s/he feels pressed for time,
or because some of "lint"'s messages are an annoyance,
how can you expect her/him to submit to blatant paperwork ?
It was only about a week ago that one of my colleagues (highly regarded
and working to a tight schedule) admitted something to the effect that
"I can't believe how long it took me to find that bug ...
... if I had run 'lint' on the program, it would have caught it right away".
It might be worthwhile to make a rule that code walkthroughs
would be based on "lint" output rather than raw source file listings,
on the principle that your colleagues will view with scorn
anyone who wastes their time by using them to perform "lint"-like checks
on code you didn't take the time to run through "lint" yourself.
Unfortunately, code walkthroughs are unpracticed in many organizations.

    If the application lends itself to type-mixing, 
    you should certainly be allowed to do it. 
    An example: using (char *) in C to point to an arbitrary object. 

Your example just points out the need for a programmer to be able
to specify, in source code, that an arbitrary object has no specific type,
rather than having to pretend that it is an array of characters.
The latter is reminiscent of the FORTRAN practice of hiding printable
characters in arrays declared to have the INTEGER type.
My view is that the character data type should be limited to bytes
that could be printed or displayed, and not used for arbitrary bit patterns;
this is not the way C was designed, and may be an unpopular view here.
Euclid has a "StorageUnit" type that is very close to what I have in mind,
and I think that Modula-2 does, also; C ought to.
For other kinds of mixing, aren't explicit casts sufficient ?

I must admit that I have not yet been absorbed into the C culture,
so it is possible that I missed the point of the followup I have excerpted.

-- Clay Phipps
    
-- 
   {allegra,amd70,cbosgd,dsd,floyd,harpo,hollywood,hpda,ihnp4,
    magic,megatest,nsc,oliveb,sri-unix,twg,varian,VisiA,wdl1}
   !fortune!phipps