papowell@umn-cs.UUCP (Patrick Powell) (05/03/87)
When the ADA language was engineered, the designers, with malice aforthought, decided to avoid using terms taken from other languages, for constructions that had slightly different semantics. The most glaring example is the use of "package" for the "module" type of construct. You can argue, I admit, that "packages" are an instantiation of a more general concept, and that "packages" don't have the same behaviour as "modules". However, I fail to see why they didn't call the "if-then-else" construct a condistat (following the same idea). I notice with amusement that the ANSI C people have been taken by the same bug. Lets look at "function prototypes". I will admit that using "function type declarations" will be anathema to some people, in that the idea that a function has a type will be very vulgar. What is the "type" of a function? Well, if we think about functions as "objects", then they can be classed as "control" objects, VS data, which has "data" objects. Now, the type of a function is the data type it will return (VOID if none), the number and type of its arguments (if any). Functions can be highly constrained types, with strict requirements about the number and type of arguements, or polymorphic, allowing a class of types on a parameters, or polygenic, with a variable number of arguments... But, by T'Great Thundering Bejaysus, a function has a type... Now we argue about control objects, and whether they are static or dynamically bound... A function prototype is a declaration of the TYPE of a function. So why not call it a function declaration, and the place where you define it, a function DEFINITION? Why introduce new jargon? Why confuse people by using the jargon when there is a perfectly acceptable existing phrase, currently available, and known to the practioners of the art, which is perfectly useful? A language definition is a continual search for a path between complexity and simplicity, and I think that people are getting a little too complex... -- Patrick Powell, Dept. Computer Science, 136 Lind Hall, 207 Church St. SE, University of Minnesota, Minneapolis, MN 55455 (612)625-3543/625-4002
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/04/87)
In article <1535@umn-cs.UUCP> papowell@umn-cs.UUCP (Patrick Powell) writes: >A function prototype is a declaration of the TYPE of a function. So >why not call it a function declaration, and the place where you define >it, a function DEFINITION? Why introduce new jargon? This one is so easy to answer that I wonder what the point of the complaint really was. There is more than one way to declare a function. The "old style" (K&R) declaration was of necessity grandfathered in when the "new style" (prototype) declaration was admitted to the language. Calling function prototypes simply "function declarations" is inaccurate when only the new style is meant. Note also that a function definition under some circumstances can serve as the function declaration. I think "prototype" is a rather good term (conforming well to normal English usage) for the specification of what you call the "type" of a function (which C programmers might easily confuse with the type RETURNED by a function, since before prototypes the function arguments were not formally part of a function's type).
chris@mimsy.UUCP (Chris Torek) (05/04/87)
In article <1535@umn-cs.UUCP> papowell@umn-cs.UUCP (Patrick Powell) writes: >A function prototype is a declaration of the TYPE of a function. So >why not call it a function declaration, and the place where you define >it, a function DEFINITION? At a guess, the reason these are called `function prototypes' rather than `function declarations' is that `function declaration' already means something else. Specifically, in main(argc, argv) ... { double atof(); ... `double atof()' is a function declaration [K&R, p. 70]. The proper prototype is double atof(char *); while the prototype for a function of no arguments is, e.g., long random(void); (which I think horrid). (If you want to see strong typing done right, look at Mesa.) (Incidentally, `K&R' and `dpANS' are jargon, too.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
msb@sq.UUCP (05/05/87)
This is a complaint about terminology in the Draft Standard: > A function prototype is a declaration of the TYPE of a function. So > why not call it a function declaration, and the place where you define > it, a function DEFINITION? Why introduce new jargon? To quote from section 3.1.2.1 of the Draft: "A function prototype is a declaration of a function that declares the types of its parameters." The new jargon is useful because it lets several sections say things like "the following behavior occurs if a prototype for the function is in scope". For instance, suppose NULL has one of the values* permitted in the Draft Standard, and setbuf() is the usual function; then if someone writes: setbuf (fp, NULL); then if setbuf() was DECLARED as: void setbuf(); the effect is implementation-dependent, but if it was declared with a PROTOTYPE, as: void setbuf (FILE *, char *); then the example does what was really wanted. Having the term "prototype" available lets this be stated more clearly. Personally, I have always found the terms "declaration" and "definition" confusing, but as they are well established, I wouldn't dream of asking for them to be changed. "Prototype" is a new term for a new thing, and both term and thing seem clearly a good idea to me. *an integral constant expression of value zero or such an expression case to type "void *". For instance, 0 or 0L or (void *)0. Mark Brader, utzoo!sq!msb C unions never strike!