Allow arbitrary capability derivations #74
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aspiwack
approved these changes
May 9, 2019
Member
aspiwack
left a comment
aspiwack
left a comment
There was a problem hiding this comment.
Ok. A few thoughts for clean up (can be done in a separate PR):
contextis not a very good name.handlerwould be accurate. But it's also rather esoteric. We should find a good name.- I think nobody should ever have to import
Capability.Constraint. Really, the way I see it, is that people import the modules for the capabilities they need, and it stops there. TheConstraintmodule should therefore be marked as hidden for Haddock, and systematically re-exported in all the capability module. Capability.Contextis a bit different, as it gives you generic tools for capabilities (and handler) which are not in the library. There should defintitly be a module for that purpose. Though its name shouldn't be tied to the handler mechanism. There was a suggestion to hide the full definition of the classes in theCapability.Readerand the like. Then that module could also have the full exported definition ofHasReader(and the other).
Let me propose that such a clean up is necessary before a release.
| context action = | ||
| let tmDict = Dict @(inner (t m)) | ||
| mDict = | ||
| -- Note: this use of 'unsafeCoerce' should be safe thanks the Coercible |
aherrmann
approved these changes
May 13, 2019
Member
aherrmann
left a comment
aherrmann
left a comment
There was a problem hiding this comment.
This looks great!
The interface of
zoomandmagnifyis also simplified a bit. Previously, those had a constraint of the form:forall m'. HasState outertag outer m' => HasState innertag inner (t m')but it seems that those were not necessary. We now only request that:
HasState innertag inner (t m)without quantifying over all
m's.
I think the motivation for this was to enforce that cap (t m') was actually derived from cap m'. It seems that this is indeed unnecessary and the new interface is certainly easier!
added 5 commits
June 14, 2019 16:45
The interface for those three functions can be simplified by removing references to "outer" capabilities and tags.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces a
Capability.Context.contextfunction that generalizes the approach taken in #73 to allow users to derive arbitrary new capabilities from the current context via a specified newtype combinator. Thezoomandmagnifyfunctions are rewritten in terms of this helper.The interface of
zoomandmagnifyis also simplified a bit. Previously, those had a constraint of the form:but it seems that those were not necessary. We now only request that:
without quantifying over all
m's.NOTE: Based on #73 ; change base branch before merging !