[comp.lang.c] aggregate constants

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