🚀 go-pugleaf

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.