Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!vsi1!altnet!uunet!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.lang.c
Subject: Re: enums
Message-ID: <11686@steinmetz.ge.com>
Date: 29 Jul 88 18:33:50 GMT
References: <1608@dataio.Data-IO.COM> <469@m3.mfci.UUCP> <1988Jul22.171612.6225@utzoo.uucp> <5447@ihlpf.ATT.COM>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 43

A comment on the emum stuff lately...

In article <5447@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
| In article <1988Jul22.171612.6225@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
| >No.  X3J11 C (it's not quite officially ANSI C yet) almost didn't include
| >enums at all, since they are so obviously a crude patch onto the language.
| >It does in fact include them, in the simplest and stupidest form possible.

  Right on! enums were added because someone's preprocessor ran out of
symbols. Then a good version of enum couldn't be added because of "prior atr."
| 
| By saying that the dpANS C version of enums is 'the simplest and stupidest
| form possible', you have implied that there are much better forms of enums
| around.  Could you please enlighten us on to what these might be?

Here are my ideas on how an enum should work. Obviously no one gave me
definitive insight, so consider this as opinion from someone who's been
using computers for a while. If it looks a lot like Pascal, perhaps
that portion of the language is more useful than the bulk of it.

- enums should be a sequence of values in increasing order. The values
  should start at zero and increase by one. This allows the ++ and --
  operators to be used in a meaningful way.

- enums should not be conceptually mixed with ints. An explicit operation
  should be required to extract the ordinal value of an enum, and to set
  an enum to a value.

- 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.

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

-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me