Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!samsung!olivea!uunet!mcsun!ukc!edcastle!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: mistaken idea of C? (was end of lisp wave?) Message-ID: <3990@skye.ed.ac.uk> Date: 22 Jan 91 18:42:53 GMT References: <127724@linus.mitre.org> <5569@turquoise.UUCP> <3954@skye.ed.ac.uk> <106389@cc.utah.edu> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 85 In article <106389@cc.utah.edu> RCAPENER@cc.utah.edu writes: >In article <3954@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes: > >Oh no! Here we go again... It is bad enough for FORTRAN users >to mistake C's libraries to be the same thing as FORTRAN's, and >Ada/Pascal/Modula-2 folks to mistake the C header files for the >being the same thing as Pascal's {INCLUDE ....} directives. But >as fellow functional language advocates, I expect LISPers to know >better. Sigh. I was assuming that in this newsgroup I wouldn't have to spell out every detail and wouldn't have to explain everything at length just to prove I knew what I was talking about. I also expected people to try to interpret my statements as true ones before concluding that they must be false. >> If we start with C and >> then add in various libraries, it starts to look fairly large too. And indeed it does start to look large. Common Lisp looks big because, for one thing, there are over 700 functions in it. The while point of my message was that (1) if more of the C libraries were considered part of the language it would start to look big just as CL does, and (2) if CL were implemented more like C, it's size wouldn't be such a burden in practice. But for some reason, you have decided that I think all the C libraries might be included in every a.out: >In C, you do not add in the libraries. You add in ONLY those >functions from that library that you requested. Not quite. You get the ones you call plus the whatever they call and so on. Moreover, Lisp could be implemented in a similar way. Indeed, some implementations are moving in that direction. But they work by throwing out what's not needed rather than by putting in only what is. There's nothing to stop them from doing it the other way, though. >> In addition, constructs with related functionality (a data type and >> procedures for operating on its instances, for example) are often >> packaged together in a module. If your program makes use of such >> facilities, you must request the appropriate module, just as you must >> include the appropriate ".h" file in C. Note: this is what we call an anology. I am not saying "header files _are_ modules". Nor am I assuming the header files contain the code. The header file (used in a certain rather common way) is analogous to an interface description. If you want to use the stdio library, for example, you will (usually) #include. I assumed that this was common knowledge. Guess not. >You do not have to #include the header file, Depends on whether you want to write the declarations yourself or not. >and a header file is NOT a module. See above. > All header files contain (at least system header files) >are type definitions, Or at least that is all they SHOULD contain. Actually, header files can include anything you want. However there are certain conventions ... And system header files contain declarations (not just type definitions) and macro definitions. > I cringe every time I am >reminded of a teacher at a University (who shall remain unnamed) telling >his students to write code they use over and over and put it in a header >file! This is NOT the way to write C! For example, the following is a >legitimate C program, and note, not one header file. I hope you don't think it's good practice to not, for example, include stdio.h when using stdio. >Hope this clears up ANY confusion about the language C. Personally, >I like both LISP and C, so please don't flame me. Well, sorry, but I couldn't let so complete a misunderstanding go uncorrected and a flame is what came out. -- jeff