----- Original Message -----From:"Paul Winalski" <paul.winalski@gmail.com>To:"Steve Johnson" <scj@yaccman.com>Cc:"Clem Cole" <clemc@ccc.com>, "TUHS main list" <tuhs@minnie.tuhs.org>Sent:Fri, 29 Dec 2017 20:52:00 -0500Subject:Re: [TUHS] origin of C header files
On 12/29/17, Steve Johnson <scj@yaccman.com> wrote:
> I begged Dennis for a solution, and he came up with #line,
> which allowed you to say to the C compiler "treat the next line as if
> it were line nnn in file fff, and following lines as successor lines
> in file fff. It instantly solved the problem, and was used multiple
> times for various applications (probably most notably cfront). So
> far as I know, many languages including FORTRAN, Pascal and Python do
> not have such a mechanism, making it awkward to use them as
> preprocessor targets.
Language processing systems where the preprocessor functionality is
implemented as a part of the compiler itself never had the "associate
the error message with the line in the original source" problem that
you described. The compiler could keep an internal table mapping the
lexical output of the preprocessor to the source lines/files that went
into the preprocessor phase. Most (all?) of DEC's and IBM's compilers
operate this way.
In keeping with UNIX's philosophy of "one image/one purpose", C's
preprocessor functionality was in a separate image from the compiler
itself. There are many advantages to this design, including that cpp
can then be used for other languages than C. But is has the
disadvantage of introducing the source correlation problem that
required the introduction of #line.
-Paul W.