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).