3 ms·

> still doesn't do even basic Pascal enumerations The term you are looking for is sum types (albeit in a gimped form in the case of Pascal). Enumerations refer

> still doesn't do even basic Pascal enumerations The term you are looking for is sum types (albeit in a gimped form in the case of Pascal). Enumerations refer to the value applied to the type, quite literally, and is identical in Pascal as every other language with enumerations, including Go. There is only so much you can do with what is little more than a counter.

samatman 2y ago
I'm fairly sure he's referring to enumerations actually. Pascal doesn't require case matching of enumerations to be exhaustive, but this can be turned on as a compiler warning in modern Pascal environments, FreePascal / Lazarus and such. Go only has enums by convention, hence the "iota dance" referred to. I've argued before that this does qualify as "having enums" but just barely. It wouldn't have been difficult to do a much better job of it, is the thing.
- randomdata 2y ago
  > Pascal doesn't require case matching of enumerations to be exhaustive Normally in Pascal you would not match on the enumeration at all, but rather on the sum types. type Foo = (Bar, Baz) case foo: Bar: ... // Matches type Bar Baz: ... // Matches type Baz The only reason for enumerations in Pascal (and other languages with similar constructs) is because under the hood the computer needs a binary representation to identify the type, and an incrementing number (an enum) is a convenient source for an identifier. In a theoretical world where the machine is magic you could have the sum types without enums, but in this reality... Thus, yes, in practice it is possible to go around the type system and get the enumerated value out with Ord(foo), but at that point its just an integer and your chance at exhaustive matching is out the window. It is the type system that allows more flexibility in what the compiler can tell you, not the values generated by the enumeration. > Go only has enums by convention "Enums by convention" would be manually typing 1, 2, 3, 4, etc. into the code. Indeed, that too is an enumeration, but not as provided by the language. Go actually has enums as a first-class feature of the language[1]. You even say so yourself later on, so this statement is rather curious. I expect you are confusing enums with sum types again. [1] Arguably Pascal doesn't even have that, only using enums as an implementation detail to support its sum types. Granted, the difference is inconsequential in practice.
  - samatman 2y ago
    Pascal enums are not sum types, because they are not the sum of multiple types. They are an enumeration of discrete values, which is why they're called enums. Sum types in Pascal are called variant records: type FooKind = (Foo, Bar, Baz); (* An enum *) FooOrBaz = record (* This is the sum type *) case foo: FooKind of Foo: (quux: Double); Bar: (zot, zap: Double); Baz: (xyzzy: String); end Rust conflates the 'enum' keyword with sum types. Pascal does not do this. One of us is confused about what a sum type is. It isn't me. As for Go, my full opinion on that subject may be found here. If you're... curious. Let's say. https://news.ycombinator.com/item?id=40224485 https://news.ycombinator.com/item?id=40224485
    - randomdata 2y ago
      > This is the sum type This is the exact same thing, except in addition to the tag there is also a data component. Yes, this is the more traditional representation of sum types, but having an "undefined" data component is still identifiable as a sum type. It is the tag that makes the union a sum type. In Typescript terms, which I think illustrates this well, it is conceptually the difference between: { kind: 0 } | { kind: 1 } and { kind: 0; data: T } | { kind: 1; data: U } Which is to say that there is no difference with respect to the discussion here. > They are an enumeration of discrete values Yes, the "tag" is populated with an enumerator. There is an enumerator involved, that it is certain, but it is outside of the type system as the user sees it. It's just an integer generated to serve as an identifier – an identifier like seen in the above examples – but provided automatically. The additional information you can gain from it, like exhaustive matching, comes at the type level, not the number itself. > Rust conflates the 'enum' keyword with sum types. Right, because it too uses an enumerator to generate the tag value. Like Ord(foo) before, you can access the enumerated in Rust with something like mem::discriminant(&foo) The spoken usage of 'enum' in Rust is ultimately misplaced, I agree. An enumerator is not a type! But it is not wrong in identifying that an enumerator is involved. It conflates 'enum' only in the very same way you have here.
      - samatman 2y ago

samatman 2y ago

I'm fairly sure he's referring to enumerations actually. Pascal doesn't require case matching of enumerations to be exhaustive, but this can be turned on as a compiler warning in modern Pascal environments, FreePascal / Lazarus and such. Go only has enums by convention, hence the "iota dance" referred to. I've argued before that this does qualify as "having enums" but just barely. It wouldn't have been difficult to do a much better job of it, is the thing.

randomdata 2y ago
> Pascal doesn't require case matching of enumerations to be exhaustive Normally in Pascal you would not match on the enumeration at all, but rather on the sum types. type Foo = (Bar, Baz) case foo: Bar: ... // Matches type Bar Baz: ... // Matches type Baz The only reason for enumerations in Pascal (and other languages with similar constructs) is because under the hood the computer needs a binary representation to identify the type, and an incrementing number (an enum) is a convenient source for an identifier. In a theoretical world where the machine is magic you could have the sum types without enums, but in this reality... Thus, yes, in practice it is possible to go around the type system and get the enumerated value out with Ord(foo), but at that point its just an integer and your chance at exhaustive matching is out the window. It is the type system that allows more flexibility in what the compiler can tell you, not the values generated by the enumeration. > Go only has enums by convention "Enums by convention" would be manually typing 1, 2, 3, 4, etc. into the code. Indeed, that too is an enumeration, but not as provided by the language. Go actually has enums as a first-class feature of the language[1]. You even say so yourself later on, so this statement is rather curious. I expect you are confusing enums with sum types again. [1] Arguably Pascal doesn't even have that, only using enums as an implementation detail to support its sum types. Granted, the difference is inconsequential in practice.
- samatman 2y ago
  Pascal enums are not sum types, because they are not the sum of multiple types. They are an enumeration of discrete values, which is why they're called enums. Sum types in Pascal are called variant records: type FooKind = (Foo, Bar, Baz); (* An enum *) FooOrBaz = record (* This is the sum type *) case foo: FooKind of Foo: (quux: Double); Bar: (zot, zap: Double); Baz: (xyzzy: String); end Rust conflates the 'enum' keyword with sum types. Pascal does not do this. One of us is confused about what a sum type is. It isn't me. As for Go, my full opinion on that subject may be found here. If you're... curious. Let's say. https://news.ycombinator.com/item?id=40224485 https://news.ycombinator.com/item?id=40224485
  - randomdata 2y ago
    > This is the sum type This is the exact same thing, except in addition to the tag there is also a data component. Yes, this is the more traditional representation of sum types, but having an "undefined" data component is still identifiable as a sum type. It is the tag that makes the union a sum type. In Typescript terms, which I think illustrates this well, it is conceptually the difference between: { kind: 0 } | { kind: 1 } and { kind: 0; data: T } | { kind: 1; data: U } Which is to say that there is no difference with respect to the discussion here. > They are an enumeration of discrete values Yes, the "tag" is populated with an enumerator. There is an enumerator involved, that it is certain, but it is outside of the type system as the user sees it. It's just an integer generated to serve as an identifier – an identifier like seen in the above examples – but provided automatically. The additional information you can gain from it, like exhaustive matching, comes at the type level, not the number itself. > Rust conflates the 'enum' keyword with sum types. Right, because it too uses an enumerator to generate the tag value. Like Ord(foo) before, you can access the enumerated in Rust with something like mem::discriminant(&foo) The spoken usage of 'enum' in Rust is ultimately misplaced, I agree. An enumerator is not a type! But it is not wrong in identifying that an enumerator is involved. It conflates 'enum' only in the very same way you have here.
    - samatman 2y ago