# What is the difference between symbol and enumerated datatypes?

I wonder what differences and relations are between symbol and enumerated types?

A symbol is a primitive datatype whose instances have a unique human-readable form

an enumerated type is a data type consisting of a set of named values called elements, members or enumerators of the type.

Since a data type is a set of values, what exactly is the data type "symbol", and the data type "enumerated"?

It seems to me that a value in an enumerated type is just a symbol.

But the first quote says that "A symbol" is a data type, which contradicts with my thought that a symbol is a value.

• This seems to me a programming, not a type-theory question. Note that there are infinitely many possible symbols (as seen e.g. in Ruby) which are not specified in the type definition, whereas enumerated types (e.g. Java, Scala) admit only finitely many values. – Raphael Aug 17 '14 at 8:46
• thanks. do you mean the data type "symbol" is the set of all possible symbols, while the data type "enumerated" is a finite subset of it and defined up to programmers? – Tim Aug 17 '14 at 13:19
• They are unrelated types. They should normally syntactically distinguishable, though I do not know all languages and have no idea of all the weird notations or confusions some language designers may choose. See my example though about enumerated types using the same token. By the way, an enumerated type with n tokens may be read as the discriminated (or tagged) union of n singleton types. In some languages, the identifiers used for the tokens are just normal identifiers, each denoting a value of the enumerated type. This is not usually the case for symbols ... at least not so directly anyway. – babou Aug 17 '14 at 19:46

This is again much a question about terminology, without only history as a possible authority to determine "what is right".

These two kinds of values are very similar in the sense that they should be considered as atomic entities, distinguished only by their representation as a string of character over some alphabet, possibly with some minor constraints regarding the use of some characters (e.g., should start with alphabetic character,). These constraint are really immaterial, since what matters mainly is whether two symbols are the same or are different.

A major difference is that the set of symbol is potentially infinite (like the set of strings meeting the constraints) though actually limited by the implementation of the language, like anything else.

An enumerated type, is defined by giving explicitly an enumeration of the values of that type, which also have a representation as a string of characters. Since the enumeration is explicit, there is only a finite number of values in an enumeration type. Languages often consider that these values are ordered in by the order of the definition. Thus these enumerated value can be compared for equality, of for order.

Symbols can only be compared for equality. Sometimes, an arbitrary (alphabetical ?) ordering may be provided as it may help for some algorithms. But there is no semantics attached to it.

In a language, You usually have only one type for symbols. However, it is easy to make more when you have data abstraction available. Symbols are usually implemented like identifier tables in interpreted languages, and can actually stand for identifiers in meta-circular interpreters.

Enumerated types are defined by the programmer, and he may define several such types. One source of problems is that he may (at least in some languages) use the same name for different enumerated values, not in the same type of course, but in different enumerated types.

type month = (January, February, March, April, ...)
type girl = (Mary, April, Nancy, Ann, ...)
type city = (London, Paris, Nancy, Roma, ...)
type writer = (Hemingway, London, ...)


Of course, I am abbreviating illegally, since the list must be completely enumerated.

But if I use the identifier Nancy in the program, I may not know which is meant, the girl or the city. This can be resolved by various means (scoping, casting, etc.)

You do not usually get this problem with symbols, as there is only one type and a specific syntax for its values.

If you can define more by abstraction, then you usually have to use different syntaxes for the values. But this is getting into other issues.

For more specific points.

Your quote would be more accurate if it said "Symbol is a primitive datatype ..." A symbol is a value in that datatype.

It is likely that some people will talk of symbols for values of an enumerated type. Another word is token. But these two words have so many uses... Again, I do not wish to enter a terminology dispute. It is moderately constructive.