It seems bizarre to me that Copper includes Union types and then, for implementation reasons, does not include so many of its basic features, and even its basic properties.
Like, what do you mean you can’t have three union members? And that the order of the union matters? These are some of the most useful properties of union types, and the arguments for what Copper did are weak sauce.
Agreed. They don't seem to understand the difference between sum types and union types. If you're worried about tags you shouldn't be considering union types in the first place, for example.
> The option type, despite being simpler than union type introduces many new concepts and requires additional knowledge that make the language more complex.
That's why I do such things in my language in a different way. Optional and union types are just library container classes. More methods may be added if necessary, internal layout may be changed, etc. without changing the language core itself. But in such an approach the language itself should provide necessary means allowing creation of such library abstractions.
One simple but non obvious (at least to me) trick when implementing tagged unions: put the union discriminator/tag at the end, not the beginning - that way a pointer to a union is also a pointer to the value, no need to increment the pointer to point past the tag after discriminating.
It's a bit like putting the length of an array at the end rather than the beginning though - you need to know its size first to know the offset.
The value of a tagged union may be like a flexible array member - in that the size of the value depends on the tag. We shouldn't need to allocate the maximum possible variant's space when most of the instances may be the smallest. Unlike a C `union`, which are a fixed size, a tagged union has no such requirement - it can be dynamically sized depending on tag.
Usually when dealing with something like 'Union(BigThing, SmallThing)' you have to allocate sizeof(BigThing + tag) in most places anyway because you need to statically know the size so that it can be a struct/array member, live on the stack etc.
The only time you can get away with only allocating the 'real' size is if you're sticking it in its own separte memory allocation and using a pointer to refer to it in the aforementioned contexts. Which, to be fair, is a sensible thing to do if BigThing is very big, as opposed to just 'on the bigger end of sane struct sizes'.
To clarify I'm talking about what you'd do in a language implementation where the actual memory layout is opaque to userspace and bit twiddling optimizations aren't making things harder to understand for everything, not what you'd do when writing handwritten C code or an api where you expect people to access the memory directly. This isn't unheard of - e.g. from my research Swift does it, some C++ stdlib implementations do it.
(Related - the rest of the bag of weird tricks that Rust and Swift and presumably other languages use to optimize enum/union layout are pretty interesting - the tag bits actually take up no extra space in many cases).
What is the best source for cross-language description of language features? Eg: “optional types”: which langs have them and how do they work? Same with “union types” etc.
There's no single oracle for these things, unfortunately. One common citation is "Types and Programming Languages" by Benjamin Pierce (2002), but otherwise people generally just use the nomenclature of a specific language and hope cross-linguistic adventurers will figure it out. I think there's somewhat less variance with more modern languages, though, so in some ways it's less of an issue than it once was.
It seems bizarre to me that Copper includes Union types and then, for implementation reasons, does not include so many of its basic features, and even its basic properties.
Like, what do you mean you can’t have three union members? And that the order of the union matters? These are some of the most useful properties of union types, and the arguments for what Copper did are weak sauce.
Agreed. They don't seem to understand the difference between sum types and union types. If you're worried about tags you shouldn't be considering union types in the first place, for example.
> The option type, despite being simpler than union type introduces many new concepts and requires additional knowledge that make the language more complex.
That's why I do such things in my language in a different way. Optional and union types are just library container classes. More methods may be added if necessary, internal layout may be changed, etc. without changing the language core itself. But in such an approach the language itself should provide necessary means allowing creation of such library abstractions.
(2025) And about CopperLang (203 points, 3 days ago, 120 comments) https://news.ycombinator.com/item?id=50308754
One simple but non obvious (at least to me) trick when implementing tagged unions: put the union discriminator/tag at the end, not the beginning - that way a pointer to a union is also a pointer to the value, no need to increment the pointer to point past the tag after discriminating.
IMO, a bad idea.
It's a bit like putting the length of an array at the end rather than the beginning though - you need to know its size first to know the offset.
The value of a tagged union may be like a flexible array member - in that the size of the value depends on the tag. We shouldn't need to allocate the maximum possible variant's space when most of the instances may be the smallest. Unlike a C `union`, which are a fixed size, a tagged union has no such requirement - it can be dynamically sized depending on tag.
Usually when dealing with something like 'Union(BigThing, SmallThing)' you have to allocate sizeof(BigThing + tag) in most places anyway because you need to statically know the size so that it can be a struct/array member, live on the stack etc.
The only time you can get away with only allocating the 'real' size is if you're sticking it in its own separte memory allocation and using a pointer to refer to it in the aforementioned contexts. Which, to be fair, is a sensible thing to do if BigThing is very big, as opposed to just 'on the bigger end of sane struct sizes'.
To clarify I'm talking about what you'd do in a language implementation where the actual memory layout is opaque to userspace and bit twiddling optimizations aren't making things harder to understand for everything, not what you'd do when writing handwritten C code or an api where you expect people to access the memory directly. This isn't unheard of - e.g. from my research Swift does it, some C++ stdlib implementations do it.
(Related - the rest of the bag of weird tricks that Rust and Swift and presumably other languages use to optimize enum/union layout are pretty interesting - the tag bits actually take up no extra space in many cases).
Pointer arithmetic on modern computers is basically free. But cache-misses caused by accessing a union tag located far away are not free.
when serializing these things it's generally going to be best to put the tag first though. That way it's cheap to figure out how to parse it.
The serialization format, does not need to be the in-memory representation format.
Unless, you do de-serialization and serialization in tight-loop I guess is it acceptable.
NOTE: A bigger problem is when you need to decide at runtime which one of the kind you have been handled.
What is the best source for cross-language description of language features? Eg: “optional types”: which langs have them and how do they work? Same with “union types” etc.
There's no single oracle for these things, unfortunately. One common citation is "Types and Programming Languages" by Benjamin Pierce (2002), but otherwise people generally just use the nomenclature of a specific language and hope cross-linguistic adventurers will figure it out. I think there's somewhat less variance with more modern languages, though, so in some ways it's less of an issue than it once was.
Rosetta code is often helpful. Not exactly for language features, necessarily: https://rosettacode.org/wiki/Monads/Maybe_monad
Swift has already answered all these questions.
i read Onion Types
Well poor design can require you to peel off multiple layers of optionals, and so they're often a significant smell just like onions are.
Shrek would argue the layers are a feature not a bug
Philomena Cunk on Programming
https://www.youtube.com/shorts/XK_D7Z-cKZ4
So shallot be...
No matter how you cut them, they'll make you cry.