[TUHS] origin of C header files

[TUHS] origin of C header files

[Doug McIlroy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

Warning: off-topic info

> I was told once that McIlroy and Morris invented macro instructions
> for assembly language.   And certainly they wrote the definitive
> paper on macros, with, as I recall, something like 10 decisions you
> needed to make about a macro processor and you could generate 1024
> different macro systems that way.  I wonder if that ever got
> published 

The suggestion that I invented macros can also be found on-line, but
it's not true. I learned of macros in 1957 or before. GE had added
a basic macro capability to an assembler; I don't know whether they
invented the idea or borrowed it. In 1959 George Mealy suggested
that Bell Labs install a similar facility in SAP (SHARE assembly
program). Doug Eastwood wrote the definition part and I handled
expansions.

Vic Vyssotsky later asked whether a macro could define a macro--a
neat idea that was obviously useful. When we went to demonstrate
it, we were chagrinned that it didn't work: definition happening
during expansion resulted in colliding calls to a low-level
string-handling subroutine that was not re-entrant. Once that
was fixed, Steve Johnson (as a high-school intern!) observed
that it allowed the macro table to serve as an addressable
memory, for which the store and load operations were MOP
(macro define) and MAC (macro call).

Probably before Steve's bright insight, Eastwood had folded
the separate macro table into the opcode table, and I had
implemented conditional assembly, iteration over a list, and
automatic generation of symbols. These features yielded
a clean Turing-complete language-extension mechanism. I
believe we were the first to achieve this power via macros.
However, with GPM, Christopher Strachey showed you don't need
conditionals; the ability to generate new macro names is
enough. It's conceivable, but unlikely, that this trick
could be done with earlier macro mechanisms.

As for publication, our macroprocessor inspired my CACM
paper, "Macro nstruction extension of compiler languages",
but the note that Steve remembers circulated only in the
Labs. A nontrivial example of our original macros in
action--a Turing machine simulator that ran completely within
the assembler--was reproduced in Peter Wegner's programming
book, so confusingly described that I am glad not to have
been acknowledged as the original author.

Doug

[TUHS] origin of C header files

[Lars Brinkhoff]

The book "Expert C Programming" claims Alan Snyder suggested the
addition of a preprocessor.

[TUHS] origin of C header files

[Wesley Parish]

Hi

I've just had an interesting experience, explaining C header files to
a nephew programmer who didn't understand them. I pointed him in the
direction of Minix as an example of a small well-engineered system
which would display their use.

Which raised the question: when did header files come into use? Who
was the first to use header files to store common system-wide or
application-wide data definitions? Was it used in any languages prior
to C?

Thanks

Wesley Parish

[TUHS] origin of C header files

[Nigel Williams]

On Fri, Dec 29, 2017 at 7:26 PM, Wesley Parish <wobblygong at gmail.com> wrote:
> Which raised the question: when did header files come into use? Who
> was the first to use header files to store common system-wide or
> application-wide data definitions? Was it used in any languages prior
> to C?

COBOL 60 (April 1960) had INCLUDE (page V-27):

http://bitsavers.trailing-edge.com/pdf/codasyl/COBOL_Report_Apr60.pdf

FUNCTION: To save the programmer effort by automatically incorporating
          library subroutines into the source program.

It even had a literal substitution mechanism to rewrite the included text.

[TUHS] origin of C header files

[Paul Winalski]

On 12/29/17, Wesley Parish <wobblygong at gmail.com> wrote:
>
> Which raised the question: when did header files come into use? Who
> was the first to use header files to store common system-wide or
> application-wide data definitions? Was it used in any languages prior
> to C?

It probably all started with macro-instructions (macros) in assembly
languages.  The assembler for System/360 in the 1960s had a pretty
complex and powerful conditional assembly and macro expansion
capability.  That technology I'm sure dates back to the 1950s.

When higher-level languages came along, programmers moving from
assembly code to a HLL would want the same sort of preprocessor
functionality.  I know that IBM PL/I had %include, and I suspect that
other HLLs of the day had similar features.

What's very clear is that C did not invent include files or
conditional compilation, it merely carried on existing tradition.

-Paul W.

[TUHS] origin of C header files

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

On Fri, Dec 29, 2017 at 2:28 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

>
> When higher-level languages came along, programmers moving from
> assembly code to a HLL would want the same sort of preprocessor
> functionality.  I know that IBM PL/I had %include, and I suspect that
> other HLLs of the day had similar features.
>
> What's very clear is that C did not invent include files or
> conditional compilation, it merely carried on existing tradition.
>


​I'll +1 Paul's comment and add a couple of observations.   Languages such
a PL/1 and FORTRAN would could support a preprocessor and conditional
compilation, were more easy to use to build 'products' - as opposed to
Pascal.    Folks did splice an backwards conditi​onal compiling scheme with
include files into some Pascal flavors but it was non-standard.

Fortran folks used tools like RATFOR or m4, but the key was the there was
some why to preprocess code for different targets.   In a production shop,
particularly where your 'target' customer was different, this ability
becomes more and more of an requirement.

I've always said as contemporary production systems programming languages,
while BLISS had a better Macro system then C, the include file and
conditional scheme worked much better/was much cleaner - to the point that
ifdef is abused and the cause of much pain in actual code.   But the truth
is that is a success problem.   When used properly, the C header scheme,
while not invented by the BTL crew, was pretty much what people needed.
 No too fancy, but all the features you really needed and has been lasting.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171229/131b2211/attachment.html>

[TUHS] origin of C header files

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4295 bytes --]

I was told once that McIlroy and Morris invented macro instructions
for assembly language.   And certainly they wrote the definitive
paper on macros, with, as I recall, something like 10 decisions you
needed to make about a macro processor and you could generate 1024
different macro systems that way.  I wonder if that ever got
published -- it blew my mind when I encountered it at the beginning of
my career...

There were two features of the C preprocessor that were, I think,
unique to the labs for some time.  One was a problem that came up
with program generators.  In RATFOR, for example, an IF statement on
line 50 might get translated to become line 125 of the output FORTRAN
program.   And if when there was an error, it could be very painful
to discover where it came from.  I ran into the same problem in
spades with Yacc.  When someone wrote a Yacc program (especially when
using a makefile), an error on line 50 in foo.y could easily be
reported as being on line 125 in foo.c.   The natural thing was to
fix the error in foo.c.   And lo, it compiled and ran.  Until the
next time you changed foo.y, and  then it reappeared in all its
glory.   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.

The other thing that I think was pretty unique was the search path for
include files (-I on the compilers).   When writing the portable C
compiler, I had a directory of source and header files that were
machine independent, and other directories that were specific to
different target architectures.   Just by changing the command line
you could compile for any desired architecture.  This would have been
a maintenance nightmare if I'd had to make different makefiles for
each desired language and keep them all in sync.

Steve

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Paul Winalski" <paul.winalski at gmail.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:
Fri, 29 Dec 2017 15:31:54 -0500
Subject:
Re: [TUHS] origin of C header files

On Fri, Dec 29, 2017 at 2:28 PM, Paul Winalski
<paul.winalski at gmail.com [1]>
 wrote:

 When higher-level languages came along, programmers moving from
 assembly code to a HLL would want the same sort of preprocessor
 functionality.  I know that IBM PL/I had %include, and I suspect
that
 other HLLs of the day had similar features.

 What's very clear is that C did not invent include files or
 conditional compilation, it merely carried on existing tradition.

​I'll +1 Paul's comment and add a couple of observations. 
 Languages such a PL/1 and FORTRAN would could support a preprocessor
and conditional compilation, were more easy to use to build 'products'
- as opposed to Pascal.    Folks did splice an backwards
conditi​onal compiling scheme with include files into some Pascal
flavors but it was non-standard.

Fortran folks used tools like RATFOR or m4, but the key was the there
was some why to preprocess code for different targets.   In a
production shop, particularly where your 'target' customer was
different, this ability becomes more and more of an requirement.

I've always said as contemporary production systems programming
languages, while BLISS had a better Macro system then C, the include
file and conditional scheme worked much better/was much cleaner - to
the point that ifdef is abused and the cause of much pain in actual
code.   But the truth is that is a success problem.   When used
properly, the C header scheme, while not invented by the BTL crew, was
pretty much what people needed.   No too fancy, but all the features
you really needed and has been lasting.

Clem

ᐧ

 

Links:
------
[1] mailto:paul.winalski at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171229/c2b8ab7a/attachment.html>

[TUHS] origin of C header files

[Paul Winalski]

On 12/29/17, Steve Johnson <scj at 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.

[TUHS] origin of C header files

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

Well, the problem is not unique to C.   If Python has such a
mechanism it doesn't seem to be used by TensorFlow.   If a TF
operation finds an error, in execution, there is, so far as I know, no
way for the error to refer back to the source Python code, or even the
variable names involved.  You have to say "name=..." for any op for
which you want to know the name -- otherwise, TensorFlow gives them
internal names that, for large designs, can be very hard to decode. 
(Of course, in TensorFlow, most of the heavy lifting is done by C++
called by a Python wrapper, that further "enhances" the debugging
experience)

Steve

----- Original Message -----
From: "Paul Winalski" <paul.winalski@gmail.com>
To:"Steve Johnson" <scj at yaccman.com>
Cc:"Clem Cole" <clemc at ccc.com>, "TUHS main list"
<tuhs at minnie.tuhs.org>
Sent:Fri, 29 Dec 2017 20:52:00 -0500
Subject:Re: [TUHS] origin of C header files

 On 12/29/17, Steve Johnson <scj at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180122/a4331c36/attachment.html>