3 ms·
> Seems like maybe this is all just a clash between formalism and how languages work in practice, I think you missed the word “broken”, before “languages”. Sum
by catnaroek 9y ago
> Seems like maybe this is all just a clash between formalism and how languages work in practice,
I think you missed the word “broken”, before “languages”. Sums in Standard ML are really sums.
> similar to how it's nice to just pretend that computers work on real numbers instead of floats.
Computers can totally work on real numbers. (Okay, not all of them. But way many more than floats allow.) For example, you can implement an abstract type whose internal representation is Cauchy streams of rationals, and only provide operations that send equivalent streams to equivalent ones. Of course, this would be horribly slow, and few people actually need exact real arithmetic anyway.
> In this case, maybe you'd need to pretend that JS works on values rather than having object identity.
JavaScript does work on values. The values are the object identities.
> See the link at the bottom for what I think foo and bar would be in TypeScript. I'm curious if you see specific weaknesses in it.
You anticipated it yourself:
https://www.typescriptlang.org/play/index.html#src=type%20A%20%3D%20%7BnumValue%3A%20number%7D%3B%0D%0Atype%20B%20%3D%20%7BstrValue%3A%20string%7D%3B%0D%0Atype%20Sum%20%3D%20%7Btype%3A%20'A'%2C%20a%3A%20A%7D%20%7C%20%7Btype%3A%20'B'%2C%20b%3A%20B%7D%3B%0D%0A%0D%0Afunction%20foo<X>(f%3A%20(s%3A%20Sum)%20%3D>%20X)%3A%20%5B(a%3A%20A)%20%3D>%20X%2C%20(b%3A%20B)%20%3D>%20X%5D%20%7B%0D%0A%20%20return%20%5B%0D%0A%20%20%20%20(a%3A%20A)%3A%20X%20%3D>%20f(%7Btype%3A%20'A'%2C%20a%7D)%2C%0D%0A%20%20%20%20(b%3A%20B)%3A%20X%20%3D>%20f(%7Btype%3A%20'B'%2C%20b%7D)%2C%0D%0A%20%20%5D%3B%0D%0A%7D%0D%0A%0D%0Afunction%20bar<X>(fa%3A%20(a%3A%20A)%20%3D>%20X%2C%20fb%3A%20(b%3A%20B)%20%3D>%20X)%3A%20(s%3A%20Sum)%20%3D>%20X%20%7B%0D%0A%20%20return%20(s%3A%20Sum)%3A%20X%20%3D>%20%7B%0D%0A%20%20%20%20if%20(s.type%20%3D%3D%3D%20'A')%20%7B%0D%0A%20%20%20%20%20%20return%20fa(s.a)%3B%0D%0A%20%20%20%20%7D%20else%20%7B%0D%0A%20%20%20%20%20%20return%20fb(s.b)%3B%0D%0A%20%20%20%20%7D%0D%0A%20%20%7D%3B%0D%0A%7D%0D%0A%0D%0Alet%20a%3A%20Sum%20%3D%20%7B%20type%3A%20'A'%2C%20a%3A%20%7B%20numValue%3A%2042%20%7D%20%7D%3B%0D%0Alet%20b%3A%20Sum%20%3D%20%7B%20type%3A%20'B'%2C%20b%3A%20%7B%20strValue%3A%20"hello%20world!"%20%7D%20%7D%3B%0D%0A%0D%0Afunction%20original(s%3A%20Sum)%3A%20boolean%20%7B%0D%0A%20%20return%20(s%20%3D%3D%20a%20%7C%7C%20s%20%3D%3D%20b)%3B%0D%0A%7D%0D%0A%0D%0Alet%20%5Bon_a%2C%20on_b%5D%20%3D%20foo(original)%3B%0D%0Alet%20reconstructed%20%3D%20bar(on_a%2C%20on_b)%3B%0D%0A%0D%0Aalert(original(a))%3B%0D%0Aalert(reconstructed(a))%3B https://www.typescriptlang.org/play/index.html#src=type%20A%...
> Do you view (say) SML datatypes as being valid sum types?
Yes. On the other hand, Haskell's aren't, albeit for different reasons than the ones given in this thread.
> I'm having a hard time understanding when SML types would be strictly more powerful/expressive than TypeScript here.
In Standard ML, type abstraction actually works. You can hide the implementation of an abstract type, making it impossible for others to destroy the invariants that you worked so hard to establish. Or at least should have.
See here for why union and intersection types make type abstraction difficult: https://news.ycombinator.com/item?id=16399722 https://news.ycombinator.com/item?id=16399722