🚀 go-pugleaf

In article <12249380101.10.PATTIS@WARD.CS.WASHINGTON.EDU>
PATTIS@WARD.CS.WASHINGTON.EDU (Richard Pattis) writes:
>... here I would like exactly what he describes - opaque types that are
>as big as the biggest "one-word" entity.

I missed the original discussion-cum-misunderstanding, but I cannot
see the problem.  In C, a language that has no direct support for
opaque types, one creates them by using a `generic pointer' type.
It is not hard to create a union (`variant record' for Pascal folks)
containing both a generic pointer and a `one word entity' (for which
C uses the word `int', as in integer: primitive perhaps, but quite
workable).  Indeed, I recently created just such a data structure:

	struct glyph {
		...		/* boring implementation stuff */
		union {		/* here comes the dirty part */
			caddr_t	un_pointer;	/* generic pointer */
			int	un_word;	/* word version */
		} g_un;
		...		/* more boring stuff */
	};

Clients of the glyph data structure can then either allocate
their own data objects:

	g->g_un.un_pointer = new_object();

or, if they have a value that they know can be represented in one
word, store it directly:

	g->g_un.un_word = integer_expression();

In a language with proper support for opaque types, a good compiler
should automatically discover that a client's supplied type fits
within the pointer word, and not bother allocating new objects.
Since the pointer word can be manipulated only by the routines
dealing with the specific object, there should never be any problem
with this.  (The supplier of the opaque type cannot assume that it
always holds an allocated object.  It must instead call the
client's freeing routine to release these objects.  This, however,
is just another implementation detail.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu