Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ucbvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!hpda!fortune!amd!decwrl!decvax!ucbvax!kupfer From: kupfer@ucbvax.UUCP (Mike Kupfer) Newsgroups: net.lang.c Subject: re: Required Declaration of C Function Parameters Message-ID: <1516@ucbvax.UUCP> Date: Sat, 4-Aug-84 19:57:14 EDT Article-I.D.: ucbvax.1516 Posted: Sat Aug 4 19:57:14 1984 Date-Received: Wed, 8-Aug-84 08:13:35 EDT Organization: U.C. Berkeley Lines: 29 > I think the key is that the type of the function `func' is just its > value type and the fact that it is a function, i.e. `t_func ()', > and the types of the parameters are not part of its formal type > although it is required that the parameter types be given in the > function declaration. This is an important distinction that solves > the problem of recursive types. This may be necessary with C's peculiar type declaration syntax, but it's not true in general. (The point being that maybe some ingenious soul can come up with an acceptable solution for C.) In Xerox's Cedar programming language, both the return type(s) and the argument types are part of the procedure's formal type. As for recursive definitions, Cedar likes the following declaration just fine: MyProcType: TYPE = PROC [MyProcType, Rope.ROPE]; which recursively defines the type of the first argument (and defines a sort of string as the type of the 2nd argument). You could use this declaration in something like: MyProc: MyProcType = {...}; -- Mike Kupfer kupfer.pa@Xerox.ARPA kupfer@Berkeley ...!ucbvax!kupfer "Even a sonic screwdriver can't get me out of this one!"