🚀 go-pugleaf

In article <49591@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes:
> To say that printf does not have a
> hetrogeneous list of arguments but rather a list of unions kind of begs
> the question.

No, it doesn't. Because varargs are a poorly defined hack, printf cannot
in practice typecheck its arguments, but the arguments are nevertheless
constrained to come from one of several types---{int,long,float,double,
ptr-to-char}, for example.

A function taking a heterogeneous argument can be given types not
specifically anticipated by the function writer. This is a necessary,
though not sufficient, restriction, which still eliminates printf.

> I see unions as hetrogeneous types
> themselves.

Unions are not heterogeneous types. Period. Except for a restriction
that union { struct { int a; ... } x; struct { int b; ... } y; } have
a and b overlap, union could be implemented as struct. (I don't recall
how ANSI formalizes this restriction.)

> I think part of the problem here is that Dan Bernstein is saying "there
> is no such thing as a hetrogeneous collection" without giving a clear
> definition of a hetrogeneous type.

I gave the canonical example of a heterogeneous type when I entered this
discussion: viz., the set of all (expressible) values. People can argue
at length about whether the set of SOME values is a heterogeneous type,
for various meanings of SOME.

> >I suspect not. After all, if a module is like printf and understands
> >all the possible types of objects in the list, it's dealing with a union
> >type. 
> And exactly how is an array of unions different from a hetrogeneous array?

How is any type different from a heterogeneous array? Among other
things, a heterogeneous array can contain types allowed by the language,
but not anticipated by whoever defines how the array is going to be used.

> >If a module does not know all the possible types, it's going to
> >see just a set of function pointers, and it won't even *want* to deal
> >with the object except through those function pointers. 
> Again, how is this different from a hetrogeneous array?

See above.

> >If there is a
> >middle case, how would you use it?
> Can you define "middle case"?

A module that does not know all the types it can deal with, but wants to
deal with more than just function pointers to perform operations.

---Dan