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

Define SListI in terms of All #32

Closed
kosmikus opened this issue Apr 13, 2017 · 3 comments · Fixed by #83
Closed

Define SListI in terms of All #32

kosmikus opened this issue Apr 13, 2017 · 3 comments · Fixed by #83
Assignees
Milestone

Comments

@kosmikus
Copy link
Member

This is a reminder for myself.

I think it would be nicer to refactor the definitions such that

type SListI = All Top

Currently, All Top implies SListI (via superclass constraint), but not vice versa. I think it'd be nicer if both are equivalent. In many cases, this would make the c and non-c versions of functions coincide.

Consider for example the following two functions as they are currently:

cpure_NP :: All c xs => proxy c -> (forall x . c x => f x) -> NP f xs
pure_NP :: SListI xs => (forall x . f x) -> NP f xs

With the equivalence, we have

pure_NP f = cpure_NP (Proxy :: Proxy Top) f
@kosmikus kosmikus self-assigned this Apr 13, 2017
@kosmikus
Copy link
Member Author

It might make sense to combine this change with the work that is in the wip-static-case branch.

@kosmikus kosmikus modified the milestone: 0.3 Apr 13, 2017
@kosmikus
Copy link
Member Author

This may be a bit tricker than expected, because GHC cannot automatically infer

All c xs => All Top xs

At the moment, SListI xs is a superclass of All c xs. We cannot have All Top xs as a superclass for All c xs because that'd be a true cycle. But the absence of the superclass constraint leads to some things failing to type-check, which is due to the lack of the implication above.

@kosmikus kosmikus added this to the 0.3 milestone Apr 19, 2017
@kosmikus
Copy link
Member Author

I've been looking at this and also the static case work again. In particular for static case, I cannot see a way currently to make it work without using undecidable super classes in such a way that it is incompatible with GHC <8. As there's currently a chance that we'll retain GHC-7 compatibility for the type-level metadata work, I'll move this from 0.3 to 0.4.

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 a pull request may close this issue.

1 participant