chris@mimsy.UUCP (Chris Torek) (07/22/87)
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 <pick a verb expressing a feeling>. 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
dsill@NSWC-OAS.arpa (Dave Sill) (07/22/87)
Chris Torek <mimsy!chris> wrote: >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' ... I always thought they were straightforward. `break' effectively does a `goto' to the statement following the innermost `while', `do', `for', or `switch', right? `continue' does an effective `goto' to the continuation test of a looping statement. >and switch >statements, and the default fall through from one switch case to >another. This *is* kind of tricky, but then this language is full of tricks. One of the things I like about C is that it allows me to do things that can't be done (as efficiently or cleanly) in other languages. This is one of those things. BTW, wasn't lint's /*FALLTHROUGH*/ supposed to help here? (It's not implemented by any of our lint's, though.) >Nonetheless, these are all part of the language we know >and <pick a verb expressing a feeling>. I think it is silly to >make major changes to a language without also renaming that language. Agreed. >(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. Especially bad when valid FORTRAN 66 code is invalid under FORTRAN 77. (Character constants, for example.) DEC, at least, has made their FORTRANs upwardly compatible, so far. >[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'....]) This is understandable, if not excusable. Programmers, of all people, should be aware of the dangers of imprecision. Don't get me wrong, I agree that different languages should have different names. But it's convenient to name the successor after the original. I think Wirth did the right thing with Pascal and Modula-2, but I can't help but wonder if Modula would have been more widely adopted if it had been given the Pascal nameplate. -Dave Sill dsill@nswc-oas.arpa