When I think of sum types, I like the categorical definition the best, which is that a sum A+B has two morphisms (i.e. constructors) Inl : A -> A+B and Inr : B -> A+B, with a simple commuting diagram[0]. Or in Rust, enum Sum { Inl(A), Inr(B), } Why do I prefer this definition? Well, category theory abstracts away irrelevant details, and sums have a "universal property" associated with them. Roughly speaking that mean…
Sum Types in Julia and Rust
11–20 of 70 posts
Re: Sum Types in Julia and Rust
#12I 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…
Re: Sum Types in Julia and Rust
#13When I think of sum types, I like the categorical definition the best, which is that a sum A+B has two morphisms (i.e. constructors) Inl : A -> A+B and Inr : B -> A+B, with a simple commuting diagram[0]. Or in Rust, enum Sum { Inl(A), Inr(B), } Why do I prefer this definition? Well, category theory abstracts away irrelevant details, and sums have a "universal property" associated with them. Roughly speaking that mean…
I don't know any category theory whatsoever. What happens in your example if A = B? Would it have two morphisms or just one?
Re: Sum Types in Julia and Rust
#14[0] https://ahsmart.com/pub/holy-traits-design-patterns-and-best...
Re: Sum Types in Julia and Rust
#15When I think of sum types, I like the categorical definition the best, which is that a sum A+B has two morphisms (i.e. constructors) Inl : A -> A+B and Inr : B -> A+B, with a simple commuting diagram[0]. Or in Rust, enum Sum { Inl(A), Inr(B), } Why do I prefer this definition? Well, category theory abstracts away irrelevant details, and sums have a "universal property" associated with them. Roughly speaking that mean…
I don't know any category theory whatsoever. What happens in your example if A = B? Would it have two morphisms or just one?
A union type "A | B" means "a value of type A or a value of type B". Example:
function f1(): String | Integer {
if (rand()) {
return "hello"
} else {
return 12
}
}
function f2(x: String | Integer) {
switch (typeof x) {
case String: return "string: " + x
case Integer: return "integer: " + x
}
}
The type "String | String" is exactly equivalent to "String".A tagged union (aka sum type) "A + B" means "either a left value or a right value; if it's the left, it has type A, if it's the right it has type B".
function g1(): String + Integer {
if (rand()) {
return Inl("hello")
} else {
return Inr("bye")
}
}
function g2(x: String + String) {
switch (x) {
case Inl(s): return "left value: " + x
case Inr(s): return "right value: " + x
}
}
The type "String + String" has one bit of additional information than just "String".Re: Sum Types in Julia and Rust
#16For this problem, I would use union types in Julia. Union types are a sort of sum, but they are amalgamated sums whilst sums types in PL semantics usually means disjoint sums. The difference is that disjoint sums 'mark' whether a value is of the left or right type, while with amalgamated sums the value may belong unmarked to the intersection. The distinction does not matter in the example the post gives.
Second, Julia does not give the benefit that Rust gives of type coverage, that is, ensuring that functions that take the sum type as argument actually are defined for each branch of the sum type. The Rust compiler guarantees this automatically. AFAICS, with Julia it is up to the user to provide tests exploring the branches.
Re: Sum Types in Julia and Rust
#17Two thoughts: For this problem, I would use union types in Julia. Union types are a sort of sum, but they are amalgamated sums whilst sums types in PL semantics usually means disjoint sums. The difference is that disjoint sums 'mark' whether a value is of the left or right type, while with amalgamated sums the value may belong unmarked to the intersection. The distinction does not matter in the example the post gives…
Re: Sum Types in Julia and Rust
#18Re: Sum Types in Julia and Rust
#19I 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
I believe another word for enums (in the Rust sense, not in the C++ or Java sense) are tagged unions.
Language designers: stop changing the meanings of words! I know you mean well and you're trying to tie unfamiliar ideas to familiar ones for beginners, but you end up causing more confusion for everyone in the long run.
Re: Sum Types in Julia and Rust
#20I 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
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...
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 typing to do than we should be doing, imo.