🚀 go-pugleaf

In article <15901@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes:
>Actually it is primarily the UNIX cc interface that conveys this 
>misconception. If you include the base of MS-DOS users who use MicroSoft
>or Lattice C, you will find that they expect to run a linker to make
>the .EXE file after compiling the source into object modules. Besides
>the frontend 'cc' the only other really popular 'all-in-one' compiler I
>can think of is Turbo PASCAL. 
>
>Further I would contend that it is a disservice to the naive user community
>to redefine the meaning of the word compiler to refer to something that
>creates and executable directly from the source. Since this same user
>might unknowingly buy a 'compiler' that conforms to the definition that 
>has been in use for the last 20 years and find out it did not do the 
>linking automatically. 

Maybe it is the people who market to the people who use that I'm
really thinking of (;-).  None of my survey of 10 compiler writers are
involved in CC like products; their compiler experience varies from
Fortran through ADA to Pascal.  There isn't a single definition of
compiler.  I'm not redefining, I'm merely reporting.

Of historical note, the concept of a single visible interface to the
complete act of generating a binary from a source goes back much farther
than CC.  In IBM systems, sophisticated parameterized batch procedures
substituted, CDC's NOS operating system has a 'RUN' command for
Fortran which does a compile load and go; and the WATFOR, WATFIV,
WATBOL systems were the outgrowth of earlier 'Load and Go' compilers.

The first actual "compiler" I ever used was on an IBM 1620, for
FORTRAN II, and it generated binary from source in one pass and then
ran the binary.  The original version had no way to save the binary;
output of binaries onto card decks was a later add on.