Sums and Products without field/constructor names

[tysonzero]

Sometimes I don't actually need/want to name the fields/constructors of my Sum or Product, I just want to have "multiple values" in the form of a Product, or I want to return "either an X, a Y or a Z". I also might benefit from functions that simply combine (add / multiply) two types, rather than having to take names into consideration.

I realize this isn't going to be as high value as Records/Variants, particularly given the language's goals, but I'd be interested to see how they would look in Expresso, and do think they provide some non-trivial value.

[willtim]

Records definitely subsume tuples, that said, I agree that writing "{ fst = x, snd = y }" is much more noisy than "(x, y)". Perhaps a reasonable solution is to provide a special tuple syntax that really just desugars to records. It could also provide built-in type synonyms for tuples, where for example "(a, b)" is the same as "{ fst : a, snd : b }" For variants, it is already possible to define something very similar to Haskell's Either using a type snonym, but this only of course handles the case of two choices. It would be painful to define them for every possible number of choices required, so perhaps a special syntax would also be desirable here, to mirror that of tuples. There is also a strong argument for positional types like tuples and choices to be inductive definitions (i.e. recursively defined, like the HList library in Haskell). This lets us implement many functions only once for all tuples/choices. Expresso does not currently support inductive definitions though,

[tysonzero]

Records do subsume Haskell-style tuples, but they don't quite subsume Products, similar to how Maps don't subsume Vectors. The difference will be more pronounced with operations that don't preserve indices like concatenation or deletion/insertion in the middle.

Inductive HList and such are definitely useful, but I think an argument can be made for contiguous positional structures as well, O(1) positional field access and all that. If implemented using an underlying Array of types (similar to how Records/Variants use an underlying Row of types). Essentially we would get all the niceness of Records/Variants but for positional Products/Sums, including only having to define one function for all sizes of them.