[Nickle]Re: structure compatibility (was: I'm confused about type promotion)

[Keith Packard]

Around 14 o'clock on Jul 24, Jamey Sharp wrote:

> > 	a struct value is compatible with a struct type if
> > 	the struct value contains all of the entries in the
> > 	type.
> 
> This sounds to me like a horrible misfeature.

This is how you deal with subtyping in a structural equivalence world.  In 
a name equivalence world, you'd need special syntax to subtype structures:

	typedef struct { int i; } i_only;
	typedef struct extend i_only { real r; } i_and_r;

Nickle uses structural equivalence to make interactive interaction easier;
name equivalence means that redefining types breaks interfaces:

	typedef struct { int i; } q;
	q f () { return (q) { i = 7; } }
	typedef struct { int i; } q;
	q x;
	x = f();

With name equivalence, the redefinition of 'q' can either:

	a)	create a new typedef, scoping out the old
	b)	insist that the two types match

a) means the example above would generate a type mismatch error, b) would
mean you could never redefine types. Structural equivalence finesses these
issues by comparing the type structure instead of the type pointers.  I 
would personally prefer name equivalence, but I don't want to wreck Nickle 
for interactive use.

C uses a mixture of structural and name equivalence:

    typedef int x_type;
    typedef int y_type;

    typedef struct { int i; } xs_type;
    typedef struct { int i; } ys_type;

    foo ()
    {
        x_type  x_value;
        y_type  y_value;
        xs_type xs_value;
        ys_type ys_value;

        y_value = x_value;		/* structural equivalence */
        ys_value = xs_value;		/* name equivalence */
    }

XCB uses the name equivalence of structure "feature" to gain some measure 
of type safety; if C had instead used pure name equivalence, XCB wouldn't 
have needed to resort to the synthetic structure type and could have just 
created a new typedef of CARD32.

Keith Packard        XFree86 Core Team        HP Cambridge Research Lab