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.

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.