Sum Types in Julia and Rust • Hacker News Board

Re: Sum Types in Julia and Rust

#41

Post by ATsch » Mon, Aug 31, 2020, 1:10 PM UTC

DaiPlusPlus wrote: post #20

renewiltord wrote: post #7

Earlier quoted context omitted.

Rust enums are full union types. i.e. while each possibility in a (say) Java enum must be of the same type, each possibility in a Rust enum can be of a different type. i.e. https://play.rust-lang.org/?version=stable&mode=debug&editio...

However, Rust's enum-type members are still named - to my knowledge you can't have anonymous enum type members in Rust. In the example you gave, the type-of `left` is still `SumType::Left` instead of being just `String`. I'm not too familiar with Rust to say, but I don't consider this to be a syntactically zero-cost abstraction (even if the wrapper-types are elided by the compiler) because we still have more keyboard…

In practice that's really not a problem because of rust's great pattern matching that easily lets you extract even deeply nested values.

Re: Sum Types in Julia and Rust

#42

Post by cdirkx » Mon, Aug 31, 2020, 1:31 PM UTC

millstone wrote: post #10

amitport wrote: post #3

I may be wrong, but I don't think this is what people mean by 'sum types'. I was expecting union types (e.g., https://www.typescriptlang.org/docs/handbook/unions-and-inte... or https://dotty.epfl.ch/docs/reference/new-types/union-types.h... ) I guess enums are a type of sum type, but seems this is more specifically about enums

Simple way to think about it is plus. Sum plus sum increases, union plus union does nothing. 1. A union type is like int | double. It means the value is one of a set of possible types. And it's a true set: `int | int | double` is indistinguishable from `int | double`. 2. A sum type is a new type built from a list of other types, which assigns a 'tag' to each possible list element, like a Rust enum. The tags are not t…

Rust also has 'union' types [1] that work similar to the union types in C, C++.

Recently there has also been a lot of discussion [2] about possibly adding anonymous enums to the language, and whether these should have sum or union semantics.

[1]https://doc.rust-lang.org/reference/items/unions.html

[2]https://internals.rust-lang.org/t/ideas-around-anonymous-enu...

Re: Sum Types in Julia and Rust

#43

Post by dan-robertson » Mon, Aug 31, 2020, 1:37 PM UTC

curryhoward wrote: post #19

enricozb wrote: post #6

Earlier quoted context omitted.

I believe another word for enums (in the Rust sense, not in the C++ or Java sense) are tagged unions.

That's right. It's unfortunate that Rust calls them "enums", since as you noted that term already had a well-established meaning in other languages, and the concept that Rust calls "enums" also had several existing names (sum type, coproduct type, disjoint union, and, more generally, algebraic data type) in the literature and in prior languages. Language designers: stop changing the meanings of words! I know you mean…

Enum has one meaning in C family languages. Other languages may have different meanings. For example, in Haskell something is an enum if there is an invertible mapping between that type and (a contiguous subset of) the machine integers (with complications).

In other languages the concept might correspond to (finite) recursively enumerable sets (ie you can list all their elements).

Re: Sum Types in Julia and Rust

#44

Post by karmakaze » Mon, Aug 31, 2020, 1:42 PM UTC

millstone wrote: post #10

amitport wrote: post #3

I may be wrong, but I don't think this is what people mean by 'sum types'. I was expecting union types (e.g., https://www.typescriptlang.org/docs/handbook/unions-and-inte... or https://dotty.epfl.ch/docs/reference/new-types/union-types.h... ) I guess enums are a type of sum type, but seems this is more specifically about enums

Simple way to think about it is plus. Sum plus sum increases, union plus union does nothing. 1. A union type is like int | double. It means the value is one of a set of possible types. And it's a true set: `int | int | double` is indistinguishable from `int | double`. 2. A sum type is a new type built from a list of other types, which assigns a 'tag' to each possible list element, like a Rust enum. The tags are not t…

I've always considered both the union and tagged union to be Sum types[0].

> Two common classes of algebraic types are product types (i.e., tuples and records) and sum types (i.e., tagged or disjoint unions, coproduct types or variant types).

Edit: e.g. X | Y isn't so different from 'a' A | 'b' B

[0] https://en.wikipedia.org/wiki/Algebraic_data_type

Re: Sum Types in Julia and Rust

#45

Post by throwaway894345 » Mon, Aug 31, 2020, 1:55 PM UTC

millstone wrote: post #10

amitport wrote: post #3

I may be wrong, but I don't think this is what people mean by 'sum types'. I was expecting union types (e.g., https://www.typescriptlang.org/docs/handbook/unions-and-inte... or https://dotty.epfl.ch/docs/reference/new-types/union-types.h... ) I guess enums are a type of sum type, but seems this is more specifically about enums

Simple way to think about it is plus. Sum plus sum increases, union plus union does nothing. 1. A union type is like int | double. It means the value is one of a set of possible types. And it's a true set: `int | int | double` is indistinguishable from `int | double`. 2. A sum type is a new type built from a list of other types, which assigns a 'tag' to each possible list element, like a Rust enum. The tags are not t…

WRT to 2, one useful property is that you can have two or more labels for the anonymous type `()`, such as `enum MyBool { True, False }` or `enum JSON { List(Array), Object(List), Number(f64), String(String), True, False, Null }`.

Re: Sum Types in Julia and Rust

#46

Post by ragnese » Mon, Aug 31, 2020, 2:12 PM UTC

thom wrote: post #38

richardwhiuk wrote: post #35

Earlier quoted context omitted.

You can flag an enum as `non_exhaustive` to indicate that it might contain additional values in the future. If you do that, then anyone writing the code must add code to handle other cases, or it's a compile error (i.e. you must match the enum as: #[non_exhaustive] enum Foo { CaseA, CaseB } let f : Foo = get_foo(); match foo { CaseA => {}, CaseB => {}, // Exhaustive matching _ => {}, } https://doc.rust-lang.org/refer…

But how can the PlayerClass trait methods get extended in the future without opening them back up to add cases to the match expression?

I'm slightly confused. First, PlayerClass is not a trait. And the methods would have to be edited when you add a case to the enum. Is that what you're asking?

It's different than if you were implementing those methods on a trait and just had several types that implemented the trait. But the article does show the potential complications that sometimes arise with Rust traits.

The difference is that a trait is "open" and an enum is "closed". So the enum's methods can/must account for all variants. A trait method calls to the implementor for work, much like inheritance in other languages.

Re: Sum Types in Julia and Rust

#47

Post by kevincox » Mon, Aug 31, 2020, 2:25 PM UTC

richardwhiuk wrote: post #37

fn greet (&self, other: &T); Yeah, this doesn't work, but the equivalent to what you are writing in Julia does: fn greet(&self, other: Box );

Or even just pass by reference if you don't need to take the box:

    fn greet(&self, other: &dyn Player);

Re: Sum Types in Julia and Rust

#48

Post by PhineasRex » Mon, Aug 31, 2020, 3:16 PM UTC

amitport wrote: post #3

I may be wrong, but I don't think this is what people mean by 'sum types'. I was expecting union types (e.g., https://www.typescriptlang.org/docs/handbook/unions-and-inte... or https://dotty.epfl.ch/docs/reference/new-types/union-types.h... ) I guess enums are a type of sum type, but seems this is more specifically about enums

This is just a difference between named and anonymous types, really. This is very similar to named functions vs lambda functions, both provide the same exact functionality but avoiding superfluous identifiers makes programming more ergonomic.

More specifically sum types in Rust must also be tagged, meaning you need to explicitly construct and deconstruct them. This aspect is along the type-alias vs newtype axis which gets into structural vs nominative typing and the trade-offs therein.

So yes, Rust enums and Typescript union types are both exactly sum-types and the differences are due to the surrounding decisions made about the languages. Rust's sum types are named and tagged, Typescript's are anonymous and untagged, but they're both sum types.

Re: Sum Types in Julia and Rust

#49

Post by lostmyoldone » Mon, Aug 31, 2020, 3:33 PM UTC

guerrilla wrote: post #27

amitport wrote: post #3

I may be wrong, but I don't think this is what people mean by 'sum types'. I was expecting union types (e.g., https://www.typescriptlang.org/docs/handbook/unions-and-inte... or https://dotty.epfl.ch/docs/reference/new-types/union-types.h... ) I guess enums are a type of sum type, but seems this is more specifically about enums

A sum type is a tagged union [1]. In C, a sum type can be modeled by the combination of an enum and a union. The enum would tell you which field of the union you should use. In Rust, enum's subsume unions and enums of C. This is analogous to a a disjoint union [2] in set theory. Notice that in both cases you have a pair of data. Sum types and disjoint unions are both instances of coproducts in category theory, by the…

According to the tagged union Wikipedia you referenced, a disjoint union is also considered a tagged union. Whether or not that's actually a correct description within the vernacular of computer science, I don't know.

"In computer science, a tagged union, also called a variant, variant record, choice type, discriminated union, disjoint union, sum type or coproduct, ..."

Re: Sum Types in Julia and Rust

#50

Post by amelius » Mon, Aug 31, 2020, 3:34 PM UTC

guerrilla wrote: post #39

amelius wrote: post #28

There are sum types, and product types, but what would "exponentiation types" look like?

Exponential types are functions [1]. The type A -> B could be written B^A. Interestingly, if you take functions to be lookup tables, then that's related to the number of possible unique lookup tables. First, notice that the type A + B has |A| + |B| values, the type A × B has |A| + |B| values and then we can see that A -> B has |B|^|A| values by remembering that functions can be seen as binary relations with the prope…

Interesting! Now I wonder what "tetrated" types correspond to [1]

[1] https://en.wikipedia.org/wiki/Tetration