{{ message }}
Repository navigation
Deprecate and eventually remove IsSymbol in favor of the Reflectable type class #4314
Description
Proposal
The type-level integers PR (#4207) introduced a poly-kinded type class for type reflection, aptly named Reflectable. Similarly, we plan to replace Symbol with String (#3103), similar to how type-level integers are kinded with the Int type. This proposal aims to deprecate the IsSymbol type class in favor of Reflectable, before eventually being removed in a v1 release of the compiler.
Examples
Any occurrence of IsSymbol can be substituted with Reflectable, and the same can be done with reflectSymbol into reflectType:
xs :: forall s. IsSymbol s => Proxy s -> String
xs = reflectSymbol
xs' :: forall s. Reflectable s String => Proxy s -> String
xs' = reflectTypeWe can add a Warn-ing to any consumers of the IsSymbol type class to use Reflectable instead.
Activity
JordanMartinez commentedon May 11, 2022
👍 from me.
However, I think a question to resolve is how this affects
Prim.Docs. Something I noticed recently is that there isn't a kindIntthere. And if there was, it has a conflict with the typeInt. By renamingSymboltoString, I imagine we would have a similar conflict.Also, this issue may be a duplicate of #3103
natefaubion commentedon May 11, 2022
There is no kind Int. The kind and type are the same thing. We should note in the docs that Int exists at the type level as well.
JordanMartinez commentedon May 11, 2022
I'll open an issue for that. The same can be said for
Boolean, right, except it's values aren'ttrueandfalsebecause that would (at least currently) clash with type vars with similar names (e.g.foo :: forall true. true -> String).natefaubion commentedon May 11, 2022
trueandfalseare reserved keywords. The identifier rules are the same for term and type level. You can't bindtrueas a type variable. There's no reason thetrueandfalsekeywords can't be made available at the type level, it's just kind of weird. At the term level you can almost say they are magic bindings to foreign values, but this doesn't really make sense for type-level names. I don't know if that's a deal breaker though. Honestly, we could have just made the keywordsTrueandFalse, and avoided all of that.JordanMartinez commentedon May 11, 2022
I think it's clearer if we continue to use
True/Falseat the type level...? And wasn'tTrue/Falseat the value-level avoided because those values aren't actual ADTs?natefaubion commentedon May 11, 2022
I guess? But we pattern match on them as an ADT, so the distinction seems completely moot to me. Take your pick:
Anyway, I don't think we will be changing that, so it doesn't really matter. If we support other literals at the type level like Int and String, then I don't know why we couldn't support
trueandfalse.f-f commentedon May 11, 2022
How about adding
TrueandFalseat the value level too? (while keeping the lowercase ones)JordanMartinez commentedon May 11, 2022
Mm.... I don't think we should do this.