Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kind-Polymorphism and Show #260

Open
csicar opened this issue Feb 20, 2021 · 3 comments
Open

Kind-Polymorphism and Show #260

csicar opened this issue Feb 20, 2021 · 3 comments
Labels
status: needs more info This issue needs more info before any action can be done.

Comments

@csicar
Copy link

csicar commented Feb 20, 2021

As of 0.14, the Proxy-Zoo should get reduced to just one: Proxy. This means that creating type-class instances for proxied values is no longer possible (as far as I know)

For example in typelevel-peano (https://github.com/csicar/purescript-typelevel-peano/pull/4/files#diff-7de00383917fea851d52cc5de4f18f87329b6b3f4e2819a8ebcbf9d8c0d85a80R47) I had a Show-Instance for typelevel Ints, that would print the value representation:

>>> instance showNat :: Show (IProxy a) where show = reflectInt
>>> show (IProxy :: IProxy N10)
10

I think it would be nice to have the same functionality for Proxy as well:

-- In Type.Proxy
class KindShow a where
  kindShow :: Proxy a -> String

instance showkindShow :: (KindShow a) => Show (Proxy a) where
  show a = kindShow a

---- In client
data Int

reflectInt = ...

instance show :: KindShow Int where
  kindShow p = reflectInt p

Does that make sense? Is there an easier way?

@JordanMartinez
Copy link
Contributor

I feel like this would be better done outside of core to see how much usage it gets, and only bring it into core (if not contrib) once the design stabilizes and we agree that it should go here.

@csicar
Copy link
Author

csicar commented Dec 3, 2021

That is understandable

I'm not sure if instance showKingShow can be defined outside of Type.Proxy, because it would be an orphan instance

@JordanMartinez
Copy link
Contributor

Ah, you're right.

Well, let me give a potentially better reason. We're currently discussing whether to even have Show in the first place (see #272). If we suddenly add it here for kinds, it feels like we're repeating history. Having a KindDebug would make more sense to me.

@JordanMartinez JordanMartinez added the status: needs more info This issue needs more info before any action can be done. label Dec 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs more info This issue needs more info before any action can be done.
Projects
None yet
Development

No branches or pull requests

2 participants