I mean union types in the programming language theory sense, not in the "we called this language feature union types" sense. Elm's union types are algebraic data types (ADTs). Union types in the PLT sense are what Typescript has. The main difference is that an ADT must be declared upfront, whilst a union type can be constructed in an ad-hoc manner based on whatever types are used together at a particular point in the program.
I used to think the same but after having many discussions just like this I accepted that there’s no agreed upon formal definition for what is a union type and what isn’t. Being created ad hoc or not seems like a made up on the spot distinction. If you do think there is a definition that most researchers agree on that’s distinct from ADT, do provide some sources.
Here's Types and Programming Languages on union types. My take away is that the preferred terminology is union types for non-disjoint unions and sum types for disjoint unions.
"Sum and variant types are sometimes called disjoint unions. The type T1+T2 is
a “union” of T1 and T2 in the sense that its elements include all the elements
from T1 and T2. This union is disjoint because the sets of elements of T1 or
T2 are tagged with inl or inr,respectively, before they are combined, so that
it is always clear whether a given element of the union comes from T1 or T2.
The phrase union type is also used to refer to untagged (non-disjoint) union
types, described in §15.7." p142
"The dual notion of union types, T1 ∨ T2, also turns out to be quite useful.
Unlike sum and variant types (which, confusingly, are sometimes also called
“unions”), T1 ∨T2 denotes the ordinary union of the set of values belonging
to T1 and the set of values belonging to T2, with no added tag to identify the
origin of a given element." p207
JVM languages always target bytecode because it’s much simpler and stable than Java as a language. It almost never changes and when it does it normally won’t break code generation since it’s only adding type system information, for example, as with records.
I had the exact same idea around 5 years ago, and actually built a language. But without a stdlib it’s a bit useless and as there was no component model at the time it was impossible to have one.
The real fear is political due to Russia's hybrid war which has pushed a lot of pro-Russia isolationist parties ahead in many EU countries. Starting a conventional war against Russia carries a higher risk of these "pro-neutrality/pro-peace" parties rising to power than any nukes dropping.
Putin is stretched very thin and this fiasco in the Ukraine has shown that Russia can barely take on one country, even though once they were touting themselves as equal or better than the US.
Sweden has plenty of cheap hydropower. But as prices are now tied to countries like Germany which made catastrophic decisions around energy, Swedes have to pay much more than if Sweden had an independent energy market.
Presumably because Sweden is selling some of that cheap power to Germany.
The solution to which is to generate even more power in Sweden (so you can sell it off cheap and have it cheap too) or that Germany produces power more cheaply so that it's not giving Sweden so much money for electricity. Both of these should happen if the market is set up well.
In that case it sounds like "unification was bad" is an unfair characterization. Unification was bad by proxy, due to the bad decisions of Germany. If Germany had made better decisions, unification would've been good as Sweden would've had lower prices on a larger market.
”Bad or good by proxy” is how all policy plays out though, your ideas mean nothing if reality says otherwise. And Germany going coal was well known by time of unification (one might think it was because of that, tinfoil hat on).
That has nothing to do with the EU, it's just capitalism. Even if the EU wouldn't exist, the energy companies would have found a way to sell the cheap Swedish hydropower to Germany.
This particular case is unique to Clojure, I believe. You definitely can’t do that in Common Lisp , and Scheme I am not so sure. It was one of the main motivations for Rich Hickey to make the language more uniform so that a few functions work on any number of data structures.
The US recognizes Taiwan as part of China since the 70’s though its position is quite ambiguous! I found this document by the US congress that explains the history behind the rather bizarre situation Taiwan finds itself today: https://www.congress.gov/crs-product/IF12503
Nope. The US One China Policy (not to be confused with China's One China Principle) only "acknowledges" China's claim over Taiwan. The wording is intended to be vague so that each side can interpret the meaning according to their own interests (like China claiming "acknowledge" actually means "recognize").
reply