Re:Elixir 1.17 released: set-theoretic types in patterns, du...
by lolinder on Wednesday June 12, 2024 @10:38AM
(#40658697)
Is the TypeScript team correct in explaining that soundness would exclude functions accepting subtypes as laid out there? If so, it seems like any type system that was meant to be able to type common JavaScript idioms would have to be unsound.
Re:Elixir 1.17 released: set-theoretic types in patterns, du...
by zarathustreal on Wednesday June 12, 2024 @01:09PM
(#40660490)
Sub-types can be represented with algebraic types so I’m not sure that’s necessarily true, for example an abstract class with subclasses can be represented as a sum type
Re:Elixir 1.17 released: set-theoretic types in patterns, du...
by zem on Wednesday June 12, 2024 @05:19PM
(#40663232)
only if there is a fixed set of subclasses, which is not always or even mostly the case.
Re:Elixir 1.17 released: set-theoretic types in patterns, du...
by deredede on Thursday June 13, 2024 @03:52AM
(#40667069)
Yes and no - you can't have bi-variant argument types as shown here and be sound, but that does not mean you can't type those idioms. You just need the type system to be able to express a dependency between the name of the event handler and the type of the associated function. It is not exactly straightforward (this is a complex type system feature) though, I don't blame the TS devs for going for an escape hatch there.
(Edit: to be clear, allowing to refine function types in the way they do is part of the solution, the unsound part is that it is not checked afaik)
That being said, I don’t think it’s possible to “pull off soundness without compromising expressivity” because the expressivity in this context is self-referential types which equate to non-terminating unification logic (and thus, unsoundness). Still, I’m excited to see what they do with this type system! Reminds me a bit of Shen’s type system.