diamond@tkou02.enet.dec.com ("diamond@tkovoa") (12/24/90)
Subject: parameter type matching (was Re: the SUN way) In article <3069@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >The second solution is more radical. It involves enhancing the language >so that we can express the idea of a type which has a name but which is >otherwise undefined (and undefinable). One possibility would be: > typedef ? T; // a generic unknown/unknowable type > void *bsearch(const void *, const T *, unsigned, unsigned, > int(*)(const T *, const T *)); >In this case, the argument matching rules would have to be made smart >enough to insist on proper matching all the way down to the point where >we hit the mystery type T. This is only a partial solution. Suppose there are four parameters of type T. How does the compiler know if all four are supposed to match, or if the first two should match each other and the last two should match each other but the last two do not have to match the first two? I am told that gcc has had a "typeof" construct for many years which might be able to solve this problem. The 1989 Extended Pascal standard does have a "type of" construct, approved in 1987, which solves exactly this problem. In C-based languages, there is a syntactic difficulty because the function's return type is specified before the parameter types. The processor has to analyze the parameters first. Here in pseudo-C syntax: typeof(x) *bsearch(const any (*x)[], const typeof(x) *, unsigned, unsigned, int(*)(const typeof(x) *, const typeof(x) *)); Notice that the first parameter names the prototype-scoped identifier x, whose type is invoked in other parts of this prototype. If the programmer wanted to name other parameters and copy their types as well, it could also be done. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/24/90)
diamond@tkou02.enet.dec.com ("diamond@tkovoa") writes: > [...] The Extended Pascal Standard does have a "type of" construct, > approved in 1987, which solves exactly this problem. In C-based > languages, there is a syntactic difficulty because the function's > return type is specified before the parameter types. The processor has > to analyze the parameters first. Here in pseudo-C syntax: > typeof(x) *bsearch(const any (*x)[], const typeof(x) *, > unsigned, unsigned, > int(*)(const typeof(x) *, const typeof(x) *)); > Notice that the first parameter names the prototype-scoped identifier > x, whose type is invoked in other parts of this prototype. If the > programmer wanted to name other parameters and copy their types as > well, it could also be done. I know that the urge to preserve C's write-only, unparsable syntax forever into the future is nearly insurmountable, but that is really ugly and hard to read. How about: typeof(x) *bsearch(const any (*x)[], const oftype(x) *, unsigned, unsigned, int(*)(const oftype(x) *, const oftype(x) *)); Also, looking at it, I would assume that "x" is of type "pointer to function", and so question the "*"s within the prototype of bsearch; i.e., it is hard to understand to what, and with what stopping point, your typing has tied x. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- But then, I was _born_ confused.
diamond@tkou02.enet.dec.com ("diamond@tkovoa") (12/31/90)
Subject: Re: parameter type matching (was Re: the SUN way) In article <1990Dec24.112015.4426@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >diamond@tkou02.enet.dec.com ("diamond@tkovoa") writes: >>Here in pseudo-C syntax: >> typeof(x) *bsearch(const any (*x)[], const typeof(x) *, >> unsigned, unsigned, >> int(*)(const typeof(x) *, const typeof(x) *)); >How about: > typeof(x) *bsearch(const any (*x)[], const oftype(x) *, > unsigned, unsigned, > int(*)(const oftype(x) *, const oftype(x) *)); My understanding was that gcc calls it typeof. (Though gcc's construct is not powerful enough to back up from the parameter declaration to the function return type. The 1989 Extended Pascal standard can do it because function return types come after the parameter declarations.) I don't care if you want to call it oftype instead of typeof. But you missed one. > typeof(x) *bsearch(const any (*x)[], const oftype(x) *, oftype >Also, looking at it, I would assume that "x" is of type "pointer to >function", and so question the "*"s within the prototype of bsearch; >i.e., it is hard to understand to what, and with what stopping point, >your typing has tied x. Huh? I said, and you correctly quoted my saying, what x was: >> Notice that the first parameter names the prototype-scoped identifier >> x, whose type is invoked in other parts of this prototype. If the >> programmer wanted to name other parameters and copy their types as >> well, it could also be done. oftype(x) *bsearch(const any (*x)[], const oftype(x) *, ----^---- In this example, x has type (const any *). [Hmm, the oftype (or whatever) construct will have to be given additional capability to remove "const" when necessary.] -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
chip@tct.uucp (Chip Salzenberg) (01/01/91)
According to xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan): > oftype(x) *bsearch(const any (*x)[], const oftype(x) *, > unsigned, unsigned, > int(*)(const oftype(x) *, const oftype(x) *)); This kind of function declaration will never be useful unless either (1) implementations are required to make all pointers the same size -- an unreasonable requirement for word-addressed machines -- or (2) functions so declared, including the comparison function, are actually defined to use |void *| in place of all the pointers to oftype(foo). By the way, the first parameter must surely be "const any *x". -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/03/91)
diamond@tkou02.enet.dec.com ("diamond@tkovoa") writes: >Subject: Re: parameter type matching (was Re: the SUN way) > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >>diamond@tkou02.enet.dec.com ("diamond@tkovoa") writes: >>>Here in pseudo-C syntax: >>> typeof(x) *bsearch(const any (*x)[], const typeof(x) *, >>> unsigned, unsigned, >>> int(*)(const typeof(x) *, const typeof(x) *)); >>How about: >> typeof(x) *bsearch(const any (*x)[], const oftype(x) *, >> unsigned, unsigned, >> int(*)(const oftype(x) *, const oftype(x) *)); > >My understanding was that gcc calls it typeof. (Though gcc's construct >is not powerful enough to back up from the parameter declaration to the >function return type. The 1989 Extended Pascal standard can do it because >function return types come after the parameter declarations.) > >I don't care if you want to call it oftype instead of typeof. >But you missed one. >> typeof(x) *bsearch(const any (*x)[], const oftype(x) *, > oftype > >>Also, looking at it, I would assume that "x" is of type "pointer to >>function", and so question the "*"s within the prototype of bsearch; >>i.e., it is hard to understand to what, and with what stopping point, >>your typing has tied x. > >Huh? I said, and you correctly quoted my saying, what x was: >>> Notice that the first parameter names the prototype-scoped identifier >>> x, whose type is invoked in other parts of this prototype. If the >>> programmer wanted to name other parameters and copy their types as >>> well, it could also be done. > oftype(x) *bsearch(const any (*x)[], const oftype(x) *, > ----^---- >In this example, x has type (const any *). [Hmm, the oftype (or whatever) >construct will have to be given additional capability to remove "const" >when necessary.] I think I'd better bow out of this discussion, after having you misunderstand me and then Chip misquote me. My primary point was that "typeof" is an operator capturing a type and assigning it a name, in this case "x". That functionality should not be confounded with the operator which returns, give a name, here "x", the type information to be used by the compiler for a cast or prototype. I was thus explicitly trying to suggest that two _different_ names be used for these two different functions, rather than forcing the compiler to guess the functionality intended from context, and the human reader to find the enclosing context to see which use is being employed. My second, separate point, was that "typeof" was being used to capture the type of a _pointer_to_ function, and should capture the "pointerness" of the type, and thus the "*"s in the body of the bsearch prototype should be redundant. Then again, it is more than possible, considering the responses, that I have misunderstood the issues completely, which is why I wish no longer to continue adding confusion to the discussion. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>