Path: utzoo!utgpu!attcan!uunet!pyrdc!pyrnj!rutgers!rochester!cornell!blandy
From: blandy@marduk.cs.cornell.edu (Jim Blandy)
Newsgroups: comp.lang.c
Subject: Re: enums
Message-ID: <19795@cornell.UUCP>
Date: 30 Jul 88 01:50:57 GMT
References: <1608@dataio.Data-IO.COM> <469@m3.mfci.UUCP> <1988Jul22.171612.6225@utzoo.uucp> <5447@ihlpf.ATT.COM> <11686@steinmetz.ge.com>
Sender: nobody@cornell.UUCP
Reply-To: blandy@cs.cornell.edu (Jim Blandy)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 66

In article <11686@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>Here are my ideas on how an enum should work...
	...
>- it would be nice to have separate namespace for the various enum
>  types. The current implementation treats enum names as if they were
>  #defined values. This was a good idea for structs, and it's a good
>  idea here. It allows development of modules wothout having to have a
>  master control for enum names. Statements like x=red would specify the
>  "red" for the enum type of x. enum type conversion could require a
>  cast.

Although I agree with the principle, I think there might be some very
difficult problems implementing a type checker to deal with this.
It's more than just storing the definitions separately (as is done
with members); enum constants don't have any special syntactic context
(members have . and ->) to say "I'm an enum constant of such-and-such
enum."

In most C compilers (all the ones I know about, in any case), type
checking is done from the bottom up; after you create the parse tree,
you type the leaves, and work your way up.  Since the type of an
expression depends completely on its subexpressions, you can be sure
you have the information by the time you need it.

In order to separate constants of different enum types, you'd need a
more powerful approach.  You'd need to use some kind of 'type
anticipation' system; in the fragment

	enum { uhlrich, zwingli } gar;
	enum { zwingli, uhlrich } bage;

	bage = zwingli;

we need to be expecting one of the enums in particular before we can
decide on the type of zwingli;  we need to carry the type over the
assignment operator.  Even worse, consider

	f(zwingli);

where f isn't prototyped...  This can't be unraveled without a cast.

Please note that structure and union members are not the same issue;
there's never any need to consider the 'member' in a "struct.member"
expression until you've found the type of the 'struct' .  The member
could never be anything complicated requiring further analysis, unlike
the right operand of =.

And how should we write our enum->int converter?  A cast? What is

	(int) zwingli;

?  We'd need a whole new syntax, another sizeof() - style thing:

	enumvalue(enumtag, enumconst)
and	enumvalue(enumvar, enumconst)	  (for untagged enums)

It's not undoable, it's just more of a pain than you might think.

>  My feeling is that the enum type is not quite abstract enough to
>justify having another construct in the language.

As mentioned before, they're handy with a symbolic debugger, but I'll
admit that that's not the best justification for a language feature.
--
Jim Blandy - blandy@crnlcs.bitnet
"And now," cried Max, "let the wild rumpus start!"