Comment by cubefox | Hacker News Reader

Comment by cubefox | Hacker News Reader

Parent Full thread

> You cannot go around claiming that 'technically' unions are not unions

I never said this. I said that there are two different kinds of unions with quite different definitions and behaviors.

> A tagged union is so called because it is a union (overlapping memory) with a field (a tag) containing a discriminator (aka discriminated union). An untagged union is a union without this tag.

That alone doesn't sufficiently describe the "unions" in set theoretic type systems like TypeScript. As I said, these unions are not disjoint and don't involve the special constructor that tagged unions/discriminated unions/sum types in algebraic type systems do. They also have logical implications like A implying A|B. Or A|A being equivalent to A, which isn't the case for discriminated/tagged unions. Maybe they are implemented similarly under the hood, but that doesn't negate the difference.

Edit: It's probably fair to say that "untagged unions" in languages like TypeScript, Ceylon or Scala 3 (set theoretic type systems) are different from "untagged unions" in C. It only adds to the confusion...

> Maybe they are implemented similarly under the hood

It's hard to know what to say to this. Tagged unions are not tagged unions, even if they are literal tagged unions? What?

I reiterate what I said in my previous comment, you're not using the ordinary definition of the term union, and this is causing confusion. A union may or may not be a "union" as understood within various academic type theories, that really depends on how any given theory defines that word, which can be any way it wants. But a union is a CS concept with a clearly understood meaning, and when used without added context to suggest it is to be interpreted in some theoretical way, it is understood in that ordinary way.

OP's article is clearly using 'union' to mean tagged unions - he even shows off their implementation, with a tag. The author assumes that his audience will understand what he's talking about when he uses the word union, and it's not causing anyone trouble in this comments section. The fact that alternative definitions within various theoretical paradigms is very nice, bless their hearts, but not really relevant.

You may prefer other definitions to the usual CS definition, that's certainly your prerogative, but - again - that's hardly grounds for taking an article and comment section that's using the commonplace meaning, and appearing to lecture others for failing to adhere to your idiosyncratic standards for what a union must be.

See my edit above. There is the C terminology, and the TypeScript et al terminology, and it's the same "untagged" terminology for two different things. In any case, both these kinds of "untagged" unions are different from tagged/discriminated unions. So just calling them "unions" is ambiguous at best and confusing at worst.

But no one is actually confused. You yourself understand what the author meant, from your comments. Everyone here understands what he meant.

It's neither ambiguous nor confusing to use the word union in CS. The only person who's making it so is you, by introducing semi-unrelated concepts from set theory that happen to have the same name as the established CS concept.

Why stop there? Maybe the author meant the Union, as in the United States? Itself quite ambiguous - does he mean the United States of Mexico, or the United States of the Ionian Islands? Is C# getting Corfu? Corfu dot net? :P

> But no one is actually confused.

Wrong, see this comment: https://news.ycombinator.com/item?id=48251896

Clearly he thought that it's the same kind of union as in TypeScript and that in C# just the syntax is weird. Which is not the case. Some others who are not commenting are probably also not aware of the two kinds of union types (or three, counting C separately).

> It's neither ambiguous nor confusing to use the word union in CS.

Well, we disagree.

I see no evidence the user is confused, they said they wished the syntax were similar to TS. Though they're not the same thing, they do have comparable uses, so it makes sense to wish for similar syntax to reduce cognitive overhead.

> Well, we disagree.

Most people here know the set theory definition of unions. It's simply a niche use, compared to the usual CS definition, which is the one used in the original article and now all the comments.

You're swimming upstream with a definition that doesn't reflect what is under discussion, which you decreed as though from on high, complete with the assertion that most people don't understand unions like you do. They do.

> they do have comparable uses, so it makes sense to wish for similar syntax to reduce cognitive overhead

No this makes no sense at all. Set theoretic types don't use special constructors, there is no way to make them look remotely similar. He is clearly not aware that these are different kinds of unions.

> They do.

Nope, precisely because they are less common. You yourself also clearly also didn't understand the difference between "untagged unions" in C and set theoretic type systems.

Uh huh, sure. I didn't know the between a C union and a set theoretic union. I'm just so gosh darn confused, trying to use them set theoretical types in my C all the time!

You have come into a room full of CS practitioners to announce to them that you alone understand what unions are. Never mind fifty years of industry practices and nomenclature - never mind the fact we all already know set theory and unlike you don't confuse set theoretic unions with tagged unions - all that can now be set aside because you discovered set theory last week and now no one understands unions except for you.

Can't wait for next week when you discover some new band, and you'll be in here telling us how no one gets music except for you. :P

Reply on news.ycombinator.com