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

Add roam method to Mapping #50

Merged
merged 1 commit into from
Jul 5, 2018
Merged

Add roam method to Mapping #50

merged 1 commit into from
Jul 5, 2018

Conversation

treeowl
Copy link
Contributor

@treeowl treeowl commented Apr 3, 2017

I don't know if this is useful or not, but Mapping
supports a roam method similar to wander.

@treeowl
Copy link
Contributor Author

treeowl commented Apr 3, 2017

Urk. I hate how Github note things work. It would be much, much nicer to use Representable here than Distributive and Applicative, but that would incur an adjunctions dependency. We need the Applicative to implement wanderMapping and for several of the Mapping instances. If we had Representable instead of Distributive, I think we could use Data.Functor.Rep.Co to get everything we need.

@treeowl
Copy link
Contributor Author

treeowl commented Apr 3, 2017

Trying to pin down the representable functor to a function doesn't seem to work too well; things that can be coercions end up not. So I guess (Distributive f, Applicative f) may be the way to go for now, sad as it is.

@treeowl treeowl force-pushed the roam branch 2 times, most recently from 3c9fb9a to 3e813d4 Compare April 3, 2017 03:04
I don't know if this is useful or not, but `Mapping`
supports a `roam` method similar to `wander`.
@phadej
Copy link
Contributor

phadej commented Apr 5, 2017

Is there some adjunction-like interaction happening between

  • Traversable1 t <-> Apply f
  • Traversable t <-> Applicative f
  • Functor f <-> Representable f (this is witnesed by Adjunction ?)
    is this your, @treeowl reasoning for use of Representable ?

@phadej
Copy link
Contributor

phadej commented Apr 5, 2017

FWIW: Settable has also Traversable. I guess it's is trivially satisfied by any Representable functor.

@treeowl
Copy link
Contributor Author

treeowl commented Apr 5, 2017

I don't know any of this theory, really. Anything Distributive should also support a Representable instance (unique, but sadly only up to isomorphism). Using that allows more functions to be passed to roam (the payoff). It also, I believe, simplifies the Kleisli and Star instance constraints to eliminate the Applicative and Monad components. We keep tacking constraints onto Distributive because (I think) we really want Representable.

The trouble with Representable, in some contexts, is that we need to expose a representation type as part of the API. I wonder if there's some way around that using TypeInType

@phadej
Copy link
Contributor

phadej commented Apr 5, 2017

And for usefulness: In profunctor based optics Representable definition is simpler, as then one can define
setting, otherwise we need to stick with collecting only (or use p ~ (->) constraint which I don't like).

type Setter s t a b = forall p. Mapping p => Optic p s t a b
type Optic p s t a b = p a b -> p s t

-- I don't see easy way to define without `Distributive` and `Applicative` only
setting :: ((a -> b) -> s -> t) -> Setter s t a b
setting f = roam $ \g s -> tabulate $ \idx ->
    f (flip index idx . g) s

-- Distributive and Applicative constraint would be enough, if one don't need `setting`
collecting
    :: (forall f. Representable f => (a -> f b) -> s -> f t)
    -> Setter s t a b
collecting = roam

EDIT:

And because we have Representable f, using Star f, we can over many inputs at once:
(it's not collectOf, as that won't allow traverse' to be there).

>>> overMany (mapped . traverse') (\i -> V2 (negate i) i) [[1,2],[3]]
V2 [[-1,-2],[-3]] [[1,2],[3]]

@ekmett ekmett merged commit 3e813d4 into ekmett:master Jul 5, 2018
treeowl added a commit to treeowl/profunctors that referenced this pull request Sep 1, 2019
I wasn't very smart about the way I defined `roam` back in ekmett#50.
As @phadej noted in ekmett#50 (comment)
it's practically unusable. Let's make it much simpler and more useful.
This is a breaking change, but I very much doubt much code will break.
@treeowl treeowl mentioned this pull request Sep 1, 2019
treeowl added a commit to treeowl/profunctors that referenced this pull request Sep 2, 2019
I wasn't very smart about the way I defined `roam` back in ekmett#50.
As @phadej noted in ekmett#50 (comment)
it's practically unusable. Let's make it much simpler and more useful.
This is a breaking change, but I very much doubt much code will break.
treeowl added a commit to treeowl/profunctors that referenced this pull request Sep 2, 2019
I wasn't very smart about the way I defined `roam` back in ekmett#50.
As @phadej noted in ekmett#50 (comment)
it's practically unusable. Let's make it much simpler and more useful.
This is a breaking change, but I very much doubt much code will break.
treeowl added a commit to treeowl/profunctors that referenced this pull request Sep 2, 2019
I wasn't very smart about the way I defined `roam` back in ekmett#50.
As @phadej noted in ekmett#50 (comment)
it's practically unusable. Let's make it much simpler and more useful.
This is a breaking change, but I very much doubt much code will break.
RyanGlScott pushed a commit that referenced this pull request Sep 2, 2019
I wasn't very smart about the way I defined `roam` back in #50.
As @phadej noted in #50 (comment)
it's practically unusable. Let's make it much simpler and more useful.
This is a breaking change, but I very much doubt much code will break.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants