Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: Conformant Arrays in C Message-ID: <715@cresswell.quintus.UUCP> Date: 1 Mar 88 07:41:18 GMT References: <42529@sun.uucp> <7297@brl-smoke.ARPA> <676@cresswell.quintus.UUCP> <996@PT.CS.CMU.EDU> Organization: Quintus Computer Systems, Mountain View, CA Lines: 52 Keywords: ANSI C, C++ In article <996@PT.CS.CMU.EDU>, edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: > In article <708@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes: > > I could write a hymn of praise to tagged unions, discrimination > > case statements, and polymorphic types, and an execration text > > for untagged unions, but let's keep it down. > > [Recall that this started with me saying that C/C++ compatibility didn't strike me as important because I thought C++ would be a better language without some of C's features, and having been challenged to name five such features, I named six. C's unions are what they are, and a good C programmer will learn to live with them. I do not advocate changing C. ] Wyatt writes: > There are tradeoffs in requiring or not requiring tag fields. > It's the space vs readablity problem again. I can't really agree. In Wyatt's own example, he makes it plain that the information as to what his unions are is held in a field, it's just that the field is somewhere else. If you are storing information about a union somewhere, what's so terrible about storing it as part of the union? There is something of a cultural conflict here. My basic preference is for languages like Simula and ML, where there is no such thing as an untagged union, and you don't have to debug using-the-wrong-union bugs because they just can't happen. This goes with a view of what a union *is*, which says that 'union' ("sum" types) is the categorial dual of 'struct' ("product" types), that the "fields" of a union are injection functions, and it goes with a pattern-matching programming style (the Simula INSPECT statement, for example). On the other hand, C has nothing but untagged union, which goes with a quite different view of what a union is, namely that it is a storage overlay. Pascal tried to compromise, which meant that it offered neither the security of sum types nor the storage efficiency of untagged unions. I think everyone will admit that sum types are theoretically clean, and that union types are riskier. Further, sum types are better news for optimising compilers. I think we can discount the "space saving" argument: if space saving were of paramount concern in C, it would have dynamically allocated arrays, not fixed-size arrays. As for transmitting things over networks, presumably there is some reason why SUN's XDR coding doesn't pack things down to byte, but works in multiples of 32 bits... C's unions are what they are, and there are legitimate uses of them. But are they a desirable feature in a successor to C? Perhaps we can steer this discussion back to something of more immediate use to C programmers: the six points I listed in the message Wyatt quoted: o do other C programmers experience them as nuisances? o how do people work around them?