Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.lang.misc Subject: Re: Look ... [or: one, two, three, many] Message-ID: <19717:Jan220:38:5491@kramden.acf.nyu.edu> Date: 2 Jan 91 20:38:54 GMT References: <19418@yunexus.YorkU.CA> <23986:Dec2703:47:1390@kramden.acf.nyu.edu> <1990Dec29.110202.3862@mathrt0.math.chalmers.se> Organization: IR Lines: 101 In article <1990Dec29.110202.3862@mathrt0.math.chalmers.se> augustss@cs.chalmers.se (Lennart Augustsson) writes: > I apologize to those who find this trivial and think it's just > a waste of time and space. Ditto. > Since Dan seems to hate computer science (or is it just computer > scientists? Btw. what do you consider yourself to be Dan?) I will > try to refrain from using computer science arguments. I don't hate computer science or computer scientists, and I don't have anything against ``computer science arguments'' (whatever those are). I consider myself a mathematician, since you ask. [ analogy between functions and integers ] [ analogy between composable functions and arbitrary-precision integers ] I agree that your analogy is reasonably close. For reasons outlined in a previous article, I would say ``C supports arbitrary-precision arithmetic'' just as strongly as ``C supports composable functions.'' (I am using ``supports'' to dodge the ambiguity of ``has.'') However, there is one important failure of the analogy. Integers really are an atomic type in C. Function pointers are not. C has first-class arithmetic built in to the language. It does not have first-class functions built in. Of course, these statements about language power ignore issues of efficiency and syntax. > The problem with the counterclaim is that it talks about a completely > different, newly defined type called func (integer), but the original > claim was about another builtin type. In this case, C does *not* have built-in first-class functions, unless you abuse terminology and take ``has'' as something syntactic. So what do you care about? If you care about what's built in, then you can go nitpick with the ANSI word-mangling committee. If you care about programming, you will solve the problem at hand and not worry about what's built in and what takes a few lines of code to implement. > Dan claims that there is no practical difference, but I think there > is a very big one. If I have tons of code that uses functions (ints) > I would have to make massive changes to be able to use that code with > these new type func (bignum). The fact that function pointers are supported more strongly than struct fun pointers is merely a matter of convention and history. Neither type is built in to the language per se. (I am referring to K&R and common C.) If I understand your argument correctly, you are saying that C ``has'' a type if and only if you can find a big enough box of library functions that depend on that type. This is insupportable. Please don't misinterpret my statements here. I do agree that there is a practical reason to use whatever code is available when it does the job. But you started by saying that C doesn't have first-class (rather, first-class composable) functions, and that's a theoretical statement with a theoretical meaning. > (You cannot write a total function that converts func to C functions any more > than you write a total function that converts bignum to int. The function > has to fail (or give a "wrong" result) for some arguments.) Actually, another poster illustrated a technique for doing exactly this, with no failures. It's a rather nice solution, though it does require ANSI C. > To state my argument concisely: If a predefined type X (function, int) > does not have property P it does not matter if it possible to define > another type that has property P, X still does not have it. C does not predefine any type which is a first-class function! Why do you keep saying it does? Either you say that C has composable functions, or you say that C doesn't have first-class functions (in the usual sense) at all. There's no way out without an appeal to syntax. I understand that you and Dave really are taking that way out, and I think we are on common ground wrt what we mean. I just don't like mixing syntax into a discussion of semantics. Next time I'll try to stay away from phrases like ``C has X.'' > Since Dan's description of Q was rather short I cannot say anything > about Q. Is it the case that you can change anything without > syntactical changes? Without recompilation? Without changes to the program text per se, always. Without recompilation, of course not. For the purposes of this discussion, C++ works the same way. > Anonymous voice says: > FORTRAN is a subset of C. This statement refers to much more than language power. In particular, C cannot deal with certain features of Fortran syntax. Therefore Fortran is not a subset of C. Why are you being facetious? ---Dan