<p>Consider a C style enum:</p>
<pre><code> enum colour {
    red,
    blue,
    green
 };
</code></pre>
<p>In haskell this would be:</p>
<pre><code> data colour = red | blue | green
</code></pre>
<p>What is the correct name for each of the possible values?
or if there isn't a single correct one what is a good one?</p>
<p>I am sure I have seen this called an <code>atom</code>. Though I am unable to find the reference.
I am inclined towards this definition as <em>an atom is an indivisible unit</em>.</p>
<p>Has anyone come across this?</p>
<p>(I think atom comes from set theory here - <a href="http://en.wikipedia.org/wiki/Urelement" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/Urelement</a> though you also see it in type theory - for example <a href="https://paigenorth.github.io/ross_lecture_notes.pdf" rel="nofollow noreferrer">https://paigenorth.github.io/ross_lecture_notes.pdf</a>)</p>
<p>Which of the following make (more) sense:</p>
<ul>
<li>red is a value</li>
<li>red is an atom</li>
<li>red is a symbol</li>
<li>red is a unit type</li>
<li>red is a label</li>
</ul>
<p>[<em>I am trying to come up with a good name for the concept which is correct from the typing point of view and ideally not too overloaded. Each of the above has different implications and pros and cons.</em>]</p>
<p><a href="https://en.wikipedia.org/wiki/Enumerated_type" rel="nofollow noreferrer">Wikipedia</a> describes an enum type theoretically as:</p>
<blockquote>
<p>In type theory, enumerated types are often regarded as tagged unions of unit types</p>
</blockquote>
<p>Is this correct? I thought there was only one unit type?
The <a href="https://en.wikipedia.org/wiki/Unit_type" rel="nofollow noreferrer">wikipedia page for unit type</a> is possibly ambiguous:</p>
<blockquote>
<p>a unit type is a type that allows only one value</p>
</blockquote>
<p>but thereafter we talk about &quot;the unit type&quot;.</p>
<p>If we say an enum is a set of unit types distinguished by their tag does that imply nominal typing?
That is (in pseudo-haskell):</p>
<pre><code> newtype tag = unit type + name
</code></pre>
<p>By this definition of univalence:</p>
<p>&quot;The principle of univalence, introduced by Vladimir Voevodsky, states that two equivalent types can be freely substituted for each other. This means that if you have two types that are equal, you can treat them as interchangeable without affecting the correctness of your program.&quot;</p>
<p>The unit types are univalent but a &quot;unit type + a name&quot; (whatever we call it) is not interchangage for a unit type + a different name because it is a &quot;new&quot; type.</p>
<hr />
<p>If I also defined:</p>
<pre><code> data trafficlight = red | amber | green
</code></pre>
<p>Is the <code>red</code> atom in <code>trafficlight</code> the same as the <code>red</code> atom in <code>colour</code>?</p>
<p>An implementer's inclination is to say yes. Your enum type is constructed internally as an array of the possible atoms.
But of course it is still wrong to assign a variable of type colour to one of type trafficlight because they (the enum types) are distinct regardless of the atoms that make them up.
Or considered another way the atoms can be re-used as members of different sets (enums).</p>

<language-design><type-systems>
What is the 'type' (and correct name) of a member of an enumeration?
CC BY-SA 4.0
2023-07-04T01:54:23.787Z
It's called a [data constructor](https://wiki.haskell.org/Constructor) in Haskell and related languages.
alephalpha
CC BY-SA 4.0
2023-07-04T08:24:09.313Z
Ruby calls this a symbol https://ruby-doc.org/core-2.6.3/Symbol.html
(but symbols are more general)
Bruce Adams
CC BY-SA 4.0
2023-07-04T08:24:25.887Z
I think atom comes from set theory here - https://en.wikipedia.org/wiki/Urelement
Bruce Adams
CC BY-SA 4.0
2023-08-31T04:56:44.380Z
"I thought there was only one unit type" - there is only one *value* of a unit type. You can have multiple distinct Unit types, just as you could have multiple distinct Bool types or distinct String types: they're just of varying usefulness.
apropos
CC BY-SA 4.0
2023-08-15T02:17:10.157Z
Lisp and Prolog use the term "atom", but in both of those languages atoms have slightly different semantics; C has no equivalent of `getprop` and `setprop`. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node108.html
Pseudonym
CC BY-SA 4.0
2023-08-15T08:12:10.113Z
"I thought there was only one unit type?" - sure, but nothing prevents you from having a union of a type with itself. If the type is tagged different ways before that union operation, it might even be useful.
Karl Knechtel
<p>For C-style enums where there is no further structure in the values, I would call them <strong>enum values</strong> or <strong>members</strong> of the enum. It might also make sense to call them just &quot;values&quot;, &quot;atoms&quot; or &quot;symbols&quot; but this is less specific since these words don't imply that they belong to an enum type. It might make sense to call them &quot;unit types&quot; <em>if</em> they are indeed types (not just values), but I think that would be confusing even if it were technically true.</p>
<p>For Rust-style enums where enum values can have their own fields, I would call them <strong>variants</strong>, since e.g. if <code>MyEnum::Foo(1, 2)</code> is one of the possible values of the enum then <code>MyEnum::Foo</code> is not a value itself, so it wouldn't make sense to call it a value or a member of the enum type.</p>
<hr />
<blockquote>
<p>Wikipedia describes an enum type theoretically as:</p>
<blockquote>
<p>In type theory, enumerated types are often regarded as tagged unions of unit types</p>
</blockquote>
<p>Is this correct? I thought there was only one unit type?</p>
</blockquote>
<p>Yes, Wikipedia is correct. It's totally possible to have distinct unit types,  but also the unit types in a tagged union don't <em>have</em> to be distinct unit types; it is the &quot;tag&quot; of the tagged union which tells them apart, not the value that gets tagged. That is, in type theory <code>1 + 1 = 2</code> even if both <code>1</code>s are the same, because that's just how sum types work.</p>
<hr />
<blockquote>
<p>If I also defined:</p>
<pre><code>data trafficlight = red | amber | green
</code></pre>
<p>Is the <code>red</code> atom in <code>trafficlight</code> the same as the <code>red</code> atom in <code>colour</code>?</p>
</blockquote>
<p>This is a matter of interpretation, so in some languages (e.g. a union of literal types or a discriminated union in Typescript) the answer could be &quot;yes&quot; and in others (e.g. Java or Rust) it could be &quot;no&quot;. In languages where enum values are just names for integers, the answer might even be &quot;yes, but only because they are both <code>0</code>&quot;.</p>

CC BY-SA 4.0
2023-07-04T01:53:52.710Z
2023-07-04T02:01:48.053Z
2023-07-04T02:01:48.053Z
kaya3
CC BY-SA 4.0
2023-07-04T02:01:27.187Z
I think `MyEnum::Foo` is called a enum constructor.
alephalpha
CC BY-SA 4.0
2023-07-04T02:03:03.800Z
@alephalpha It can be, but I think it is more general to call it a variant, since the name `MyEnum::Foo` can also occur in patterns where it *de*structs values instead of constructing them.
kaya3
CC BY-SA 4.0
2023-07-04T02:24:43.980Z
`MyEnum::Foo` is a value by itself, though its type is some [function item type](https://doc.rust-lang.org/stable/reference/types/function-item.html) instead of `MyEnum`. This value is called a enum constructor. In other cases, I agree that "variant" is a better name.
alephalpha
CC BY-SA 4.0
2023-07-04T02:46:21.857Z
They're called _cases_ in Swift, because of the syntax: `enum MyEnum { case foo(Int, Int) }`.
Bbrk24
CC BY-SA 4.0
2023-07-04T07:44:01.367Z
I find rust's use of the word "enum" to mean discriminated union baffling. If you combine too things you should take the name from the more general concept and discriminated unions are definitely more general.
Bruce Adams
CC BY-SA 4.0
2023-07-04T07:54:28.670Z
If we say an enum is a set of unit types distinguished by their tag does that imply nominal typing?     That is   newtype tag = unit type + name
Bruce Adams
CC BY-SA 4.0
2023-07-04T08:29:02.837Z
See https://cs.stackexchange.com/questions/125233/doubts-on-the-behavior-of-unit-type-in-a-type-system
Bruce Adams
CC BY-SA 4.0
2023-07-04T12:49:02.583Z
@BruceAdams Yes, Rust's overloading of the word "enum" is unfortunate, but I thought I should mention it regardless. Distinguishing tagged union members by their tag doesn't imply nominal typing; it depends if tags can be shared between different types. In a nominal type system they wouldn't, of course, but in e.g. Typescript or Python where the language already contains a way to distinguish, say, strings and numbers from each other at runtime, then a union like `string | number` is a kind of tagged union, where the tag is innately present in the values already.
kaya3
CC BY-SA 4.0
2023-07-04T13:45:41.930Z
What do you mean "tags can be shared between different types"? Do you mean colour.red vs trafficlight.red or that the tag might be a field in the union rather than some kind of RTTI? I'm not sure about how that affects nominal typing.
Bruce Adams
CC BY-SA 4.0
2023-07-04T14:11:33.563Z
@BruceAdams A tagged union value is represented as a tuple like `(tag, value)`, so e.g. `color` could be `{(0, red), (1 green), (2, blue)}`. When `value` is a unit, it may as well be zero-sized, so the memory representation of the `(tag, value)` would be the same as just `tag`. Since the compiler can choose whatever tags it likes, it could choose to give non-overlapping tags to distinct enums, or it could give equal tags to different enums' members when their names are equal, or it could give tags that are numbered from 0 for each enum (then they would overlap by coincidence).
kaya3
CC BY-SA 4.0
2023-07-04T14:13:28.217Z
Of course, even if the tags happen to be equal by coincidence or otherwise, a static type system could very well treat them differently based on their static type so that `color.red == trafficlight.red` can't even be written in the language because of a type mismatch, even if the values have the same bit pattern. So the point is really just that it's up the language how this works, type theory itself doesn't say it has to be one way or the other.
kaya3
CC BY-SA 4.0
2023-08-20T13:29:51.813Z
Swift users commonly refer to variants as *cases*, because of how they're written in the language: `enum Example { case foo(Int); case bar(String) }`. I've described empty enums like `Never` as having ["no cases"](https://forums.swift.org/t/std-byte-imported-as-uninhabited-type/65527/5), for example.
Bbrk24
<p>The example you give is a sum type and its elements could be called summands but it is not common outside of theory papers.</p>
<pre><code>data colour = red | blue | green
</code></pre>
<p>A record type would be a product type and its constituents are factors but they are commonly called elements or fields.</p>

CC BY-SA 4.0
2023-08-20T09:01:55.790Z
2023-08-20T11:50:19.453Z
2023-08-20T11:50:19.453Z
Christian Lindig
<p>I usually just call them constants (for the names) and primitive values (for their value, like what true and false are usually called). Enum values could be more clear in the context of a specific language, where in most cases, all such values that are not built-in are defined in a enum.</p>
<p>But in the context of language design, while it may not answer the question, I usually call a enum type a &quot;foreign key type&quot;, for the foreign keys in a relational database could give much more insights about enums than what all the languages have implemented. Their value unfortunately has the very ambiguous name in general context, a reference to a row or a record from another table.</p>

CC BY-SA 4.0
2023-07-04T02:22:59.970Z
2023-07-04T02:22:59.970Z
user23013
CC BY-SA 4.0
2023-07-04T12:40:19.513Z
Are you saying that in your writing, the phrase "foreign key type" means "enumerated type"? I don't understand that at all.
Sophie Swett
CC BY-SA 4.0
2023-07-04T15:17:13.433Z
If the purpose of looking for a name is to find more information and get a more concise definition about it, this may provide something without providing a good name.
user23013
CC BY-SA 4.0
2023-07-04T15:35:52.357Z
I'm having a lot of trouble understanding what you're saying. I think I'm missing some of the context; I don't know whether you're talking about programming languages, databases, or both, and I know that you've mentioned both enumerated types and foreign keys, but I can't piece together the details of what you're saying about them. Could you give an example illustrating what you mean?
Sophie Swett
CC BY-SA 4.0
2023-07-04T16:49:54.077Z
I think he has interpreted my question as I am looking for a good name for an "enumeration" which is certainly part of the question. Though the type theory part is in some ways more interesting.
Bruce Adams
<p><a href="https://en.cppreference.com/w/cpp/language/enum" rel="nofollow noreferrer">Cppreference calls them &quot;enumerators&quot;</a> which I think is a well fitting term.</p>

CC BY-SA 4.0
2023-08-16T17:44:25.923Z
2023-08-16T17:44:25.923Z
chrysante
<p>In my compiler and IR, they are called enum literals. In essence, because their properties are much like those of integer literals.</p>
<p>Most of your proposals already imply a specific kind of interpretation of what an enum is. However, there are many variations of the concept and not all can be combined with the proposals made here. For instance, some languages allow enum constants from different types to be mixed. Some introduce the literal names in the global scope, others introduce them inside the scope of the enclosing type. The base type and ability to perform runtime type checks vary as well. Thus, using names from type or set theory should only be done for enum concepts that naturally fit those theories.</p>
<p>The word label is a bit odd as it is usually associated with control flow.</p>

CC BY-SA 4.0
2023-08-16T18:45:46.280Z
2023-08-16T18:45:46.280Z
feldentm
<p>PHP calls them <a href="https://www.php.net/manual/en/language.enumerations.basics.php" rel="nofollow noreferrer">legal values</a>, in the context of <a href="https://www.php.net/manual/en/language.enumerations.overview.php" rel="nofollow noreferrer">making invalid states unrepresentable</a>, but declares each member with the keyword <code>case</code>, as it avoids adding another keyword on language.</p>

CC BY-SA 4.0
2023-08-21T16:33:13.317Z
2023-08-21T16:33:13.317Z
André L F S Bacci
# What is the 'type' (and correct name) of a member of an enumeration?
Posted by: username_0 on 2023-07-04
Consider a C style enum:
 enum colour {
    red,
    blue,
    green
 };

In haskell this would be:
 data colour = red | blue | green

What is the correct name for each of the possible values?
or if there isn't a single correct one what is a good one?
I am sure I have seen this called an atom. Though I am unable to find the reference.
I am inclined towards this definition as an atom is an indivisible unit.
Has anyone come across this?
(I think atom comes from set theory here - http://en.wikipedia.org/wiki/Urelement though you also see it in type theory - for example https://paigenorth.github.io/ross_lecture_notes.pdf)
Which of the following make (more) sense:

red is a value
red is an atom
red is a symbol
red is a unit type
red is a label

[I am trying to come up with a good name for the concept which is correct from the typing point of view and ideally not too overloaded. Each of the above has different implications and pros and cons.]
Wikipedia describes an enum type theoretically as:

In type theory, enumerated types are often regarded as tagged unions of unit types

Is this correct? I thought there was only one unit type?
The wikipedia page for unit type is possibly ambiguous:

a unit type is a type that allows only one value

but thereafter we talk about "the unit type".
If we say an enum is a set of unit types distinguished by their tag does that imply nominal typing?
That is (in pseudo-haskell):
 newtype tag = unit type + name

By this definition of univalence:
"The principle of univalence, introduced by Vladimir Voevodsky, states that two equivalent types can be freely substituted for each other. This means that if you have two types that are equal, you can treat them as interchangeable without affecting the correctness of your program."
The unit types are univalent but a "unit type + a name" (whatever we call it) is not interchangage for a unit type + a different name because it is a "new" type.

If I also defined:
 data trafficlight = red | amber | green

Is the red atom in trafficlight the same as the red atom in colour?
An implementer's inclination is to say yes. Your enum type is constructed internally as an array of the possible atoms.
But of course it is still wrong to assign a variable of type colour to one of type trafficlight because they (the enum types) are distinct regardless of the atoms that make them up.
Or considered another way the atoms can be re-used as members of different sets (enums).
**Tags:** language-design type-systems
> **Comments:**
> **username_1**: It's called a [data constructor](https://wiki.haskell.org/Constructor) in Haskell and related languages.  
> **username_0**: Ruby calls this a symbol https://ruby-doc.org/core-2.6.3/Symbol.html
(but symbols are more general)  
> **username_0**: I think atom comes from set theory here - https://en.wikipedia.org/wiki/Urelement  
> **username_3**: Lisp and Prolog use the term "atom", but in both of those languages atoms have slightly different semantics; C has no equivalent of `getprop` and `setprop`. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node108.html  
> **username_4**: "I thought there was only one unit type?" - sure, but nothing prevents you from having a union of a type with itself. If the type is tagged different ways before that union operation, it might even be useful.  
> **username_2**: "I thought there was only one unit type" - there is only one *value* of a unit type. You can have multiple distinct Unit types, just as you could have multiple distinct Bool types or distinct String types: they're just of varying usefulness.  
---
## 6 answers
### Answer by username_5 on 2023-07-04. Score: 8
For C-style enums where there is no further structure in the values, I would call them enum values or members of the enum. It might also make sense to call them just "values", "atoms" or "symbols" but this is less specific since these words don't imply that they belong to an enum type. It might make sense to call them "unit types" if they are indeed types (not just values), but I think that would be confusing even if it were technically true.
For Rust-style enums where enum values can have their own fields, I would call them variants, since e.g. if MyEnum::Foo(1, 2) is one of the possible values of the enum then MyEnum::Foo is not a value itself, so it wouldn't make sense to call it a value or a member of the enum type.


Wikipedia describes an enum type theoretically as:

In type theory, enumerated types are often regarded as tagged unions of unit types

Is this correct? I thought there was only one unit type?

Yes, Wikipedia is correct. It's totally possible to have distinct unit types,  but also the unit types in a tagged union don't have to be distinct unit types; it is the "tag" of the tagged union which tells them apart, not the value that gets tagged. That is, in type theory 1 + 1 = 2 even if both 1s are the same, because that's just how sum types work.


If I also defined:
data trafficlight = red | amber | green

Is the red atom in trafficlight the same as the red atom in colour?

This is a matter of interpretation, so in some languages (e.g. a union of literal types or a discriminated union in Typescript) the answer could be "yes" and in others (e.g. Java or Rust) it could be "no". In languages where enum values are just names for integers, the answer might even be "yes, but only because they are both 0".
> **Comments:**
> **username_1** (2023-07-04): I think `MyEnum::Foo` is called a enum constructor.  
> **username_5** (2023-07-04): @alephalpha It can be, but I think it is more general to call it a variant, since the name `MyEnum::Foo` can also occur in patterns where it *de*structs values instead of constructing them.  
> **username_1** (2023-07-04): `MyEnum::Foo` is a value by itself, though its type is some [function item type](https://doc.rust-lang.org/stable/reference/types/function-item.html) instead of `MyEnum`. This value is called a enum constructor. In other cases, I agree that "variant" is a better name.  
> **username_6** (2023-07-04): They're called _cases_ in Swift, because of the syntax: `enum MyEnum { case foo(Int, Int) }`.  
> **username_0** (2023-07-04): I find rust's use of the word "enum" to mean discriminated union baffling. If you combine too things you should take the name from the more general concept and discriminated unions are definitely more general.  
> **username_0** (2023-07-04): If we say an enum is a set of unit types distinguished by their tag does that imply nominal typing?     That is   newtype tag = unit type + name  
> **username_0** (2023-07-04): See https://cs.stackexchange.com/questions/125233/doubts-on-the-behavior-of-unit-type-in-a-type-system  
> **username_5** (2023-07-04): @BruceAdams Yes, Rust's overloading of the word "enum" is unfortunate, but I thought I should mention it regardless. Distinguishing tagged union members by their tag doesn't imply nominal typing; it depends if tags can be shared between different types. In a nominal type system they wouldn't, of course, but in e.g. Typescript or Python where the language already contains a way to distinguish, say, strings and numbers from each other at runtime, then a union like `string | number` is a kind of tagged union, where the tag is innately present in the values already.  
> **username_0** (2023-07-04): What do you mean "tags can be shared between different types"? Do you mean colour.red vs trafficlight.red or that the tag might be a field in the union rather than some kind of RTTI? I'm not sure about how that affects nominal typing.  
> **username_5** (2023-07-04): @BruceAdams A tagged union value is represented as a tuple like `(tag, value)`, so e.g. `color` could be `{(0, red), (1 green), (2, blue)}`. When `value` is a unit, it may as well be zero-sized, so the memory representation of the `(tag, value)` would be the same as just `tag`. Since the compiler can choose whatever tags it likes, it could choose to give non-overlapping tags to distinct enums, or it could give equal tags to different enums' members when their names are equal, or it could give tags that are numbered from 0 for each enum (then they would overlap by coincidence).  
> **username_5** (2023-07-04): Of course, even if the tags happen to be equal by coincidence or otherwise, a static type system could very well treat them differently based on their static type so that `color.red == trafficlight.red` can't even be written in the language because of a type mismatch, even if the values have the same bit pattern. So the point is really just that it's up the language how this works, type theory itself doesn't say it has to be one way or the other.  
> **username_6** (2023-08-20): Swift users commonly refer to variants as *cases*, because of how they're written in the language: `enum Example { case foo(Int); case bar(String) }`. I've described empty enums like `Never` as having ["no cases"](https://forums.swift.org/t/std-byte-imported-as-uninhabited-type/65527/5), for example.  
---
### Answer by username_7 on 2023-08-20. Score: 2
The example you give is a sum type and its elements could be called summands but it is not common outside of theory papers.
data colour = red | blue | green

A record type would be a product type and its constituents are factors but they are commonly called elements or fields.
---
### Answer by username_8 on 2023-07-04. Score: 1
I usually just call them constants (for the names) and primitive values (for their value, like what true and false are usually called). Enum values could be more clear in the context of a specific language, where in most cases, all such values that are not built-in are defined in a enum.

But in the context of language design, while it may not answer the question, I usually call a enum type a "foreign key type", for the foreign keys in a relational database could give much more insights about enums than what all the languages have implemented. Their value unfortunately has the very ambiguous name in general context, a reference to a row or a record from another table.
> **Comments:**
> **username_9** (2023-07-04): Are you saying that in your writing, the phrase "foreign key type" means "enumerated type"? I don't understand that at all.  
> **username_8** (2023-07-04): If the purpose of looking for a name is to find more information and get a more concise definition about it, this may provide something without providing a good name.  
> **username_9** (2023-07-04): I'm having a lot of trouble understanding what you're saying. I think I'm missing some of the context; I don't know whether you're talking about programming languages, databases, or both, and I know that you've mentioned both enumerated types and foreign keys, but I can't piece together the details of what you're saying about them. Could you give an example illustrating what you mean?  
> **username_0** (2023-07-04): I think he has interpreted my question as I am looking for a good name for an "enumeration" which is certainly part of the question. Though the type theory part is in some ways more interesting.  
---
### Answer by username_10 on 2023-08-16. Score: 1
[Cppreference calls them "enumerators"](https://en.cppreference.com/w/cpp/language/enum) which I think is a well fitting term.
---
### Answer by username_11 on 2023-08-16. Score: 1
In my compiler and IR, they are called enum literals. In essence, because their properties are much like those of integer literals.

Most of your proposals already imply a specific kind of interpretation of what an enum is. However, there are many variations of the concept and not all can be combined with the proposals made here. For instance, some languages allow enum constants from different types to be mixed. Some introduce the literal names in the global scope, others introduce them inside the scope of the enclosing type. The base type and ability to perform runtime type checks vary as well. Thus, using names from type or set theory should only be done for enum concepts that naturally fit those theories.

The word label is a bit odd as it is usually associated with control flow.
---
### Answer by username_12 on 2023-08-21. Score: 1
PHP calls them [legal values](https://www.php.net/manual/en/language.enumerations.basics.php), in the context of [making invalid states unrepresentable](https://www.php.net/manual/en/language.enumerations.overview.php), but declares each member with the keyword `case`, as it avoids adding another keyword on language.
---
