Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: aggregate constants (in this case, unions) Message-ID: <7640@mimsy.UUCP> Date: Wed, 22-Jul-87 06:58:08 EDT Article-I.D.: mimsy.7640 Posted: Wed Jul 22 06:58:08 1987 Date-Received: Fri, 24-Jul-87 02:49:43 EDT References: <18346@ucbvax.BERKELEY.EDU> <8042@utzoo.UUCP> <2210@hoptoad.uucp> <732@jenny.cl.cam.ac.uk> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 47 In article <732@jenny.cl.cam.ac.uk> am@cl.cam.ac.uk (Alan Mycroft) writes: > in1: A -> union(A,B) in2: B -> union(A,B) > out1: union(A,B) -> A out2: union(A,B) -> B. >Now we see the problem: C in its hackerish wisdom only provides the 'out' >functions via the (e).member construct. >The other functions one has to hack using temporaries (see below). >Now one should sympathise with those who wish casts of objects >into a union type containing that object -- they only want a >very natural concept. Unfortunately, existing C syntax is insufficient: >In C we could say >union intorptr { int a; char *b;}; >extern f(union intorptr); >g() { f((union intorptr)3);} NOT IN ANSI. In this case the proper union element is `obvious' from the types of the union members. If, however, we had typedef asciicode char; union intorasciicode { int i; asciicode c; }; g() { f((union intorasciicode) 48); } does this mean the integer 48, or the ASCII character '0'? (There are many possible solutions to this dilemma, but they all either require syntactic extensions or are, in my opinion, ugly and error prone.) This sort of thing is why I claim that the single most important omission in C is aggregate constant types. Other deficiencies include the odd semantics of `break' vs. `continue' and switch statements, and the default fall through from one switch case to another. Nonetheless, these are all part of the language we know and. I think it is silly to make major changes to a language without also renaming that language. (E.g., the difference between FORTRAN 77 and FORTRAN 66 is sufficient that the 1977 standard should have been called something else. FORTRAN 8X also should not be called `FORTRAN'. But this is ruled by politics, not logic. [Attaching the standard date to the base name suffices, but people often talk about code written in `FORTRAN' without specifying *which* FORTRAN. I have seen this lead to what I can only call `interesting misunderstandings'....]) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris