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

Remove lingering references to KProxy #158

Merged
merged 2 commits into from
Aug 30, 2016
Merged

Remove lingering references to KProxy #158

merged 2 commits into from
Aug 30, 2016

Conversation

RyanGlScott
Copy link
Collaborator

#148 removed uses of KProxy from the codebase, but it's still lurking in a couple of places:

  • The ByHand2 test
  • An outdated comment about orphan instances in Data.Promotion.Prelude.Enum. Since it's outdated, I opted to remove the whole comment (and the unnecessary -fno-warn-orphans flag).
  • The README. But see my inline comment.

class SingKind k where
type DemoteRep k :: *
fromSing :: Sing (a :: k) -> DemoteRep k
toSing :: DemoteRep k -> SomeSing k

This class is used to convert a singleton value back to a value in the
original, unrefined ADT. The `fromSing` method converts, say, a
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Further down, this says:

The DemoteRep associated
kind-indexed type family maps a proxy of the kind Nat
back to the type Nat.

This is no longer true, but I'm not sure what I should change this to. Should I just say "maps Nat to Nat"? I don't know if that really elucidates what the purpose of DemoteRep is. Maybe we ought to give an example where DemoteRep k /= k? (Speaking of which, should the default definition of DemoteRep be DemoteRep k = k?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The obvious example where DemoteRep k /= k is TyFun with ->.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. However, I just realized that it still makes sense to distinguish between the kind-level Nat and the type-level Nat (between which DemoteRep facilitates the transition), so I simply updated the description to state that.

@RyanGlScott
Copy link
Collaborator Author

Urk, the Travis build failed due to tasty-golden failing to build with optparse-applicative-0.13: UnkindPartition/tasty#145 (comment)

@RyanGlScott
Copy link
Collaborator Author

There we go, the build is green now. All good to go.

@goldfirere goldfirere merged commit d6f69f4 into goldfirere:master Aug 30, 2016
@goldfirere
Copy link
Owner

Hooray!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants