31–40 of 70 posts
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
There are sum types, and product types, but what would "exponentiation types" look like?
The sum of a type with m possible values and a type with n possible values has (m+n) possible values, the product of a type with m possible values and a type with n possible values has (m×n) possible values, a sequence of n items of a type with m possible values has m^n possible values.
Two 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…
Julia is a dynamic language, I don't think having the rigor of a compiled language (probably the most rigorous out there) is a reasonable expectation. It would be nice to have as an external linter service, probably.
Someone Rustier than I am, what's the story with this enum solution when I want to add a _new_ star later? Can one implement this in a way that respects the open-closed principle?
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
_ => {},
}
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 Colour {
Red,
Blue,
Green,
}
fn greet(&self, other: &T);
fn greet(&self, other: Box);Someone Rustier than I am, what's the story with this enum solution when I want to add a _new_ star later? Can one implement this in a way that respects the open-closed principle?
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…
There are sum types, and product types, but what would "exponentiation types" look like?
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 );
edit - Alright I think I see what the original article was trying to express. In the original article that top example method was defined as part of a trait. Because that method is generic that would make the trait not object safe. On its own that is fine (this would still compile), but there was some previous example code which relied on this trait being object safe.