On 1/03/2011, at 11:34 PM, Kari Laitinen wrote:
> In my earlier post I said that it has been said that the printf
> function does not belong to the C language. In the paper
> http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1991.pdf
> Ritchie et al. discuss the C language.
> They say on page 2015 (page 25 in the PDF file) that "The C language
> provides no facility for I/O.", and they continue discussing how
> things would be if the printf function would be built into the language.
For one thing, look at the date. That's 1978. That's back when
different structs in C did not define different name spaces -- which is
why to this day structs in the POSIX interface often have otherwise
pointless prefixes on the member names. It's when the compiler had to
fit into a 16-bit address space.
I think you have misunderstood what Ritchie was talking about.
Programming languages like Fortran and COBOL and PL/I and Pascal
and Visual Basic have special *SYNTAX* for I/O, like
WRITE (UNIT = 6, FMT = '1XI12') (KOUNT(I), I = 1,N)
which would be expressed in C as
for (i = 0; i < n; i++) printf(" %12d", kount[i]);
> I understand this so that Ritchie et al. think that printf does
> not belong to the C language.
Wrong tense. That is what Ritchie *thought* 33 years ago, if indeed
he thought it. He certainly talks about the "STANDARD library" in
that paper. Try to tell a C programmer that 'malloc' is not part of
C and s/he will laugh you to scorn. I don't know that he ever *did*
think that printf didn't "belong to the C language" in the sense
relevant here. The *parser* doesn't have to be aware of it, and in
a 16-bit environment that's a huge advantage. But it isn't *optional*;
a C programmer does have to be aware of it.
To put it another way,
The C Programming Language, 2nd edition
Kernighan and Ritchie
is available on line at
http://cgip.inf.unideb.hu/eng/rtornai/Kernighan_Ritchie_Language_C.pdf
Chapter 7 starts with the sentence "Input and output are not part of
the C language itself", true. But that doesn't mean what you want it
to mean. It means ONLY that the compiler doesn't HAVE to know
anything special about the transput functions other than what the
<stdio.h> header tells it. It doesn't mean, and the C standard
explicitly denies that it means, that the compiler isn't ALLOWED to
know all about the standard library functions. It does not mean,
and the C standard explcitly denies that it means, that these names
may be freely used for other purposes. On the contrary, the space
of reserved special names in C is actually extremely large.
After all, if I/O isn't part of the language, what's it doing in a
book whose whole reason for existence is to describe that language?
If you look at Algol 68, which rather tepidly inspired some of the
aspects of C, you will discover that it too has an I/O library that
uses no special syntax. But I/O is spelled out as a required part
of the Algol 68 language in the defining report, and it is spelled
out as a required part of the language in the C standards too.
> Obviously these computer scientists
> think that only those textual symbols (keywords) that are built into
> the compiler belong to the programming language.
Kernighan and Ritchie were using 'language' in the sense of 'that
which MUST be specially known by a parser', i.e., syntax. If that is
all you mean, it is uncontentious and unilluminating. If you mean
anything else, you cannot appeal to them for support.
I note that one of the features which they relegated to the library
(setjmp/longjmp) is still part of the library in C89 and C99 *but*
has special syntactic restrictions on where it can be used because
it *requires* every special support from a compiler. Just because
something is defined in the 'library' chapter instead of the 'syntax'
chapter doesn't mean that the compiler can afford to be ignorant of it.
>
> As it seems to be so difficult to define what does or does
> not belong to a (programming) language,
That is part of a programming language which is specified in its
defining document. Period. We've been writing language definitions
for about 60 years. We learned how to be pretty darned good at it,
and then the industry forgot what had been learned. If something
is in the defining document, you are entitled to expect it to be
_there_ and can demand your money back if it isn't. It's part of
the language.
> I thought that it might
> be useful to think that each computer program or any other document
> contains a language of its own.
But this is inconsistent with the way you used 'language' above.
You defined the "language" of C in effect to be the *syntax* of C,
which C programs share. It is the *vocabulary* which varies from
program to program or document to document.
Are the mechanisms by which programmers learn the meanings of identifiers
in programs at all similar to the mechanisms by which people learn the
meanings of new words? Is learning what a Horcrux is like learning what
tryMergingInto means? Is either of these things done the way learning
grammar is done, or are they different mental modules?
I accept the distinction between grammar and vocabulary and deny that
either of them on its own is "language".
--
The Open University is incorporated by Royal Charter (RC 000391), an exempt
charity in England & Wales and a charity registered in Scotland (SC 038302).
