I’m really sorry to hear that lifting variant types to the compiler is not something on the agenda. I really think it is part of the overall polish of the language before a 1.0 release.
@hdgarrood: I think there is a clear distinction between using regular variants and polymorphic variants: regular variants are nominally typed and can be recursive, polymorphic variants are structurally typed and can’t be recursive. Use regular variants everywhere, only use poly variants when extendability is required or for interop with foreign functions. This is the way ReScript promotes poly variants.
Developers ask for poly variants sometimes, and having it baked into the language is way more discoverable and allows us to better explain how it should be used. Doesn’t matter if they are not as powerful as poly variants on OCaml/Reason/ReScript, they already nicely fit in because of PureScript’s row types. I think the symmetry with records, which are built in, would be beautiful, everything is already there!
Extending the argumentation of @natefaubion, we could remove record syntax from the language and write prj @"fieldname" record instead of record.fieldname, but it would harm readability a lot. I think something like
allToString :: [.Foo Int, .Bar Boolean, .Baz String] -> String
allToString = case _ of
.Foo x -> show
.Bar y -> if y then "true" else "false"
.Baz z -> z
reads way better than above example. Nothing has to be done to type inferencing, because the way it needs to work is the way its working now, but maybe error messages could be improved in the future.
But hey, maybe I’m just to much striving to symmetry with the usage of structural records in PureScript 