More accurately define union types

[thejohnfreeman]

Eliminate inaccuracies and a misleading example. A union type does not necessarily inherit the operations of its component types, much less operations across values of two different component types. The ability to add a string and a number is a quirk in JavaScript and other languages, not a feature of union types.

[clarus]

Thanks for the clarifications. I would also distinguish the union types and the sum types. Indeed, the union types aim to mimick the set operation of union, while the sum types add a tag to each case. For example, the union of a string and a string is a string, while the sum of two strings is not, since you have a tag to distinguish the two cases. For this reason, some people also call sum types disjoint unions.

To me, the sum types are a core concept of functional programming (with the product types), but the union types are more useful to model dynamic languages with instrospection.

[thejohnfreeman]

I've not heard that distinction before. To me, the terms are synonyms. Disjoint union is just the categorical sum for sets. A tag is just an implementation detail. Languages with run-time type information carry the tag with the value. In JavaScript, the tag is accessible through typeof. In languages with first-class support for sum types, e.g. Haskell, the tag is a constructor. Other languages are more ad-hoc. In C and C++, the general convention is to reserve the first field of a union as the tag.

[clarus]

In JavaScript, the tag is accessible through typeof

In the example of the union of a string and a string, the typeof operator cannot help you to distinguish the two cases. The Wikipedia references of these two (different) kinds of types:

• union types
• sum types

[thejohnfreeman]

@clarus I see what you're getting at now. Those don't exist in functional programming, but I guess the distinction is worth making.

@jethrolarson The previous example didn't show a practical usage either, but it was misleading. This example is an improvement, even if incomplete in the interest of brevity (which seems to fit the approach of the rest of the document). You're welcome, as is everyone else, to improve the example as you see fit. JavaScript is ill-suited to demonstrate these concepts in the first place.

[hemanth]

JavaScript is ill-suited to demonstrate these concepts in the first place.

Well, that is debatable.

But using an anti-pattern is a bad idea for an example?

[jethrolarson]

Clearly a non-typechecked language is underpowered for describing algebraic data types. To get any of the same utility you need to use something like union-type, daggy, etc. Even then the role of types is different. I'm not sure what would make an illuminating example without including some library or making some strong assumptions about what user defined types should mean in JavaScript.

In the original example constructors weren't used but I'd hoped to describe the type of a function based on the valid sets of values it accepts. Even without custom type support in js I think it still makes some sense to describe code in this way.

On Sun, Jul 24, 2016, 9:56 PM hemanth.hm notifications@github.com wrote:

JavaScript is ill-suited to demonstrate these concepts in the first place.

Well, that is debatable.

But using an anti-pattern is a bad idea for an example?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/pull/58#issuecomment-234839621, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4ADNV5IGOgR0H_P5gz7XLPe55sJhks5qZEHogaJpZM4JTnUm .

[stereobooster]

I haven't seen this PR before posting my issues (#117).

The ability to add a string and a number is a quirk in JavaScript and other languages, not a feature of union types.

Yep. This is coercion. Implicit coercion: 1 + "a" = "1a" or 1+1.1 = 2.1. Explicit coercion: 1.toString()+"1" = "11".

[jethrolarson]

No movement in a year, so I'm closing. Can reopen if there's reason