[ On Sunday, January 30, 2000 at 03:19:00 (-0500), der Mouse wrote: ]
> Subject: Re: ARGSUSED and friends
>
> There is a tension here between two values:
> 
> (1) One job per program, one program per job
> 
> (2) Don't do the same thing two different places
> 
> As you say, (1) certainly argues for making the compiler fast and lean,
> with minimal checking.  (Indeed, carried to an extreme, it would not
> even do syntax checking, with the results for syntax errors being
> "whatever the implementation happens to give", the philosophy being
> that you should check the code before you compile it.)

Indeed and I can forsee a simple enough addition to the make rules that
would implement a mode where new code changes were always linted before
being compiled but un-changed modules would just be compiled if their
object modules had been removed.

> But (2) is also forceful.  Putting the checking and the compiler in the
> same program means that neither has to duplicate work the other already
> does, by which I mean everything from parsing to data flow analysis.
> It also guarantees that you never find version skew between the checker
> and the compiler.

I think the basic goals of #2 are accomplished by sharing the duplicate
code between the compiler and the lint tool.  There are already some
parts of a C compiler that are almost always implemented as separate
programs, some of which are obviously sharable, and indeed the
user-interface needs the compiler and the lint tool would suggest having
separate front-end driver programs in any case.

> There's yet another argument in favor of doing checking and compiling
> in a single program: that way seems to have less trouble finding people
> to work on it.  Compare the amount of development available for new gcc
> work versus the amount of effort available for souping up lint and/or
> building a "lean and mean" compiler.

The problem is that to do all of the important checks that only a
lint-like tool can do you need a different back-end stage and sometimes
storage of intermediate parse trees (lint libraries), whether you always
run the lint-backend in parallel, in sequence with the code generator,
or from completely separate front-end drivers.

I would be extremely happy to see the GCC folks build such a back-end
(or accept and integrate one if it was built for them).

I'm also intruigued by the various potential benefits that can come from
having a completely separate pre-processor and parser for the lint
tool.  I'm not yet convinced that these benefits are outweighed by the
cost of developing and maintaining them, especially given that such a
lint tool can be just as widely used as a portable compiler with many
code generators.  Inevitable finger-pointing about which nit-picker is
right can these days often be settled by pointing at the standards
(not that I'm advocating current C standards as models of perfection!).

Unfortunately I'd rather use a compiler or lint tool than write one
(even though I think I'm still capable of doing minor maintenance on
either :-).

There are, BTW, other freely available compilers (well at least one! :-)
that don't have GCC's bloat and from what I've heard often compare
favourably in their ability to generate good code.  They also don't have
GCC's vast array of back-ends and host portability (yet)....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>