Hare doesn't care much about mathematical purity, and the features it does have were chosen on the basis of what is useful in systems programming.

There are sum types (tagged unions), but product types (tuples) were a late addition and we still don't have support for tuple unpacking or pattern matching on them.

Tuple unpacking is something that's been put off for very long but looks like it is going to finally happen soon. Pattern matching on types other than tagged unions hasn't been completely ruled out yet, but is also not guaranteed to happen.

They are a subset, I suppose. I'm not an expert at functional programming so I couldn't say. The tutorial which introduces tagged unions is here:

https://harelang.org/tutorials/introduction/#tagged-unions-i...

They are also covered in section 6.5.18 of the Hare specification:

https://harelang.org/specification.pdf

Would be curious to hear your thoughts on how they compare given your (presumed) background in functional programming.

The biggest missing feature here would be a way to not only select by type and for example allow something like

   type foo = (A int | B int)

Which from my cursory reading does not seem to be possible?

I'm not sure what you mean by "select by type". I can say that you can define new types:

   type a = int;
   type b = int;
   type c = (a | b);

Which seems to be what you're angling for here? I also suspect that you're approaching this from a Rust- or Zig-like background where enums and tagged unions are closely related; this is not so in Hare.

I do know those languages, but this is more the ADT way from ML.

The example you linked did not really make it clear from my point of view because one of the points is that it will collapse if there are multiples of a specific type. But your way seems to make it possible.

Tagged unions of free-floating types (polymorphic variants, C++ std::variant) and enum holding cases namespaced within themselves (Rust/Haskell) are two alternative designs. I personally prefer having both in a language. But if only one is available in a language, I prefer free-floating types, since it's more flexible and allows using the same type in multiple tagged unions, and you can somewhat emulate enums using tagged unions and namespaces (like I've done in C++ at https://gitlab.com/exotracker/exotracker-cpp/-/blob/eb8458b2...). If you take that approach, to prevent collapsing in the generic case when two type parameters are the same, you'd have to define newtypes for each type stored in a union.

Right - but defining a type alias makes a new type, which does not collapse.

Thank you, from the other replies it seems like they would be enough for my needs.

> Would be curious to hear your thoughts on how they compare given your (presumed) background in functional programming.

I'm just a student with an interest in programming languages and very little knowledge and experience, so I don't think I'll be able to provide any significant insight ;)