Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!princeton!allegra!ulysses!mhuxt!ihnp4!chinet!steinmetz!putnam
From: putnam@steinmetz.UUCP
Newsgroups: comp.lang.misc
Subject: Re: Check the Arg Count
Message-ID: <1067@steinmetz.steinmetz.UUCP>
Date: Thu, 8-Jan-87 07:33:42 EST
Article-I.D.: steinmet.1067
Posted: Thu Jan  8 07:33:42 1987
Date-Received: Fri, 9-Jan-87 06:32:50 EST
References: <3214@bu-cs.BU.EDU> <4900@mimsy.UUCP>
Reply-To: putnam@thuban.steinmetz.UUCP (putnam)
Organization: General Electric CRD, Schenectady, NY
Lines: 43

In article <4900@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes:

>You still haven't explained why lint as a processor should be logically and
>functionally distinct from cc as a processor.  The ONLY reason I can see for
>separating them is so that you don't have to be confronted with messages
>telling you that you're writng tricky or otherwise dubious code.

I dont want to get into a "to lint or not to lint" fight here, but i 
do think that there are very good reasons to keep lint separate from cc :

In a large system, lint looks at everything, and in "edit-run-think-debug..."
loops, the overhead of lint is unnecessary and unhelpful. (I change a
loop from "for (i=0 ; i < 100 ; i++)" to "for (i=0 ; i < 101 ; i++)", and
need to re-lint the file.  Absurd.

I might be building something that produces C code as output, and linting
it will be expensive, and will require that i build in the annotations to
keep lint happy as i build the processor.  This will interfere with my
concentrating on the important structure of the program.

I (or the people i work for) might have a modified lint with strong 
stylistic guidelines, or... which should be run instead.

In general, i believe that it is a good idea to keep things which are
logically separate, separate.  Thus, i like having a c compiler which
keeps the preprocessor, the compiler, the assembler, .... all
distinct.  In this way i can change a processor that does that step
when i need to, omit steps (where that makes sense), or add additional
steps (like editing the assembler).  Most of the time, i do not do
this, but i have needed to in the past, and found difficulties with
compilers that would not let me get to intermediate stages.  (I needed
to get at the assembler output to do something once, and the only way
to do it was to use the flag that produced an assembler listing
(interleaved with the code, and the results of the assembly!), then
edit the listing to produce usable assembler - and that didnt even
assemble correctly without more work.)

Keep separate parts separate!  Wasnt this part of the "Unix(tm) Philosophy"?

-- 
               O                   -- jefu
       tell me all about           -- UUCP: steinmetz!putnam
Anna Livia! I want to hear all.... -- ARPA: putnam@GE-CRD