Path: utzoo!utgpu!watmath!clyde!att!ucbvax!bloom-beacon!athena.mit.edu!scs
From: scs@athena.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: Passing types to a subroutine
Message-ID: <8053@bloom-beacon.MIT.EDU>
Date: 19 Nov 88 08:39:06 GMT
References: <14457@mimsy.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 122

In article <14457@mimsy.UUCP> sjr@mimsy.UUCP (Stephen J. Roznowski) writes:
>How do you pass the knowledge of the array type to the
>subroutine?

Interestingly enough, I have recently been contemplating adding
exactly this sort of feature to the C interpreter I fiddle with
from time to time.  The interpreter already has a "typeof"
command; for instance you can say

	ci> int (*pfi)();
	ci> typeof pfi
	pointer to function returning int

("typeof" is therefore half of cdecl).  As currently implemented,
"typeof" is a special command, not an operator like sizeof().
I realized that I could make it a true operator by

     1.	Adding a new type "type" to the internal list of types
	(int, long, double, etc.).

     2.	Having the typeof() operator return this new type-holding
	type.

     3.	Have the value printout routine (which prints the value
	of each "immediate mode" expression entered, in an
	appropriate format) print the cdecl form ("pointer
	to...") for an expression that returned type "type."

The next step is that you should also be able to use the "return
value" of this typeof operator in declarations and casts,
although it starts doing radical things to the grammar.  For
instance, you'd like to be able to say

	#define Swap(a, b)						\
		{							\
		typeof(a) tmp;	/* declare tmp having same type as a */	\
		tmp = a;						\
		a = b;							\
		b = tmp;						\
		}

but this means that the grammar for a declaration is (or
includes)

	declaration:
		expression declarator-list ;

with a semantic rule restricting the expression to be of type
"type."  This new production seems like it might introduce
ambiguities or unintended side effects.  Does it also mean that
the keyword "int" would now be an expression of type "type," or
should the above rule be in addition to the traditional

	declaration:
		declaration-specifiers declarator-list ;

Finally, what about casts?  You'd want to be able to say

	a = (typeof(b))c;

to cast c to b's type.  This form is even less likely to be
deterministically parseable.

This "meta-type" mechanism could conceivably handle Stephen's
problem well:

	main()
	{
	float	a[100];
	subroutine(typeof(*a), a[100]);
	}

	subroutine(t, a)
	type t;
	t a[];

Note that this example uses an explicit '*' on the array a as the
argument to typeof(), assuming that typeof(), like sizeof(), does
not implicitly convert arrays to pointers.  This example also
assumes that the declaration of the subroutine's formal parameter
"a" is "finished" at run time.  (Previous articles have discussed
supplying the dimensions of formal and/or local arrays via a
parameter at run time, which Fortran and gcc are able to do, but
is not standard C.)  Doing stuff on the fly like this is of
course trivial for an interpreter; in fact it's hard for the
interpreter not to allow things like this.  (My favorite is

	int array[getuid()];

which works just fine.)

In the above example, the fact that you'd also like to be able to
say

	subroutine(double, a2);

would be an argument in favor of redefining the primary type
names to be expressions of type "type."  (What kind of infinite
recursion does that apply for the new keyword "type" which
declares variables of type "type?")

Additional observations:

	These new "types" are really nothing more than run-time
	typedefs.

	They're really only implementable in an interpreter,
	since they defer almost everything to run time.

	Do pointers to these things ("type *tp;") mean anything?

I don't claim to have originated the idea of a type as a type;
I'm sure I've seen it in other languages.  (It's probably been
discussed here before as well.)

Please note that I am most emphatically not proposing this as an
extension to C, but merely speculating.  Since this is
far-fetched and not completely thought out, any comments should
perhaps be sent by mail rather than bewildering the net.

                                            Steve Summit
                                            scs@adam.pika.mit.edu