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

(WIP) A mess of new concepts #45

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

(WIP) A mess of new concepts #45

wants to merge 3 commits into from

Conversation

b-mehta
Copy link
Contributor

@b-mehta b-mehta commented Aug 6, 2019

WIP:

Changes introduced:

  • There are two sorts of traversable: Prelude.Traversable t in which
traverse :: Prelude.Applicative e => (a -> e b) -> t a -> e (t b)

or Data.Traversable t in which

traverse :: Data.Applicative e => (a ->. e b) -> t a ->. e (t b)

So, there should be two notions of a Traversal, and there must be two versions of the Wandering type class. Here, due to lack of imagination, they are prefixed P and D.

    • More linearity for get and set. Naturally, these two cannot be linear as usually written: get discards part of its argument, and set throws away the old information. However they can be given type signatures which reflect these facts and are stronger than just non-linear arrows.
      Setting is easy to deal with: we can just return the original value that was replaced, then running snd afterwards recovers the non-linear set. The idea is that set' can have a type signature that promises more, but degrades nicely to the standard one.

    • Getting is a little more complex: We define a 'wastebasket' of resources, Top, which has the property that forall x. x ->. Top is inhabited (uniquely). It thus forms a (linear) monoid.
      The use of Top here is that arrows a ->. (Top, b) are something of an intermediate between a ->. b and a -> b; they promise that a is not used more than once, but can't promise that all of a is used. For example, we can define (a,b) ->. (Top, b), which gets the second component and 'throws away' the first component. Again, if the extra linearity promise isn't helpful, post-composing with snd will recover the usual get.
      (Aside: the writer monad writing to Top has its Kleisli arrows as the above arrows, so we can nicely compose these functions: maybe there is some use to a promise that the argument is used no more than once)

To write: the lens constructor and a deconstructor? Pair. Wrapped semigroups

@b-mehta
Copy link
Contributor Author

b-mehta commented Aug 6, 2019

Idea:
Lenses have type forall f. Control.Functor f => (s, f b)->. (a, f t)
Const Top is a control functor which will extract the get part, and identity recovers set. The fact that all control functors are strong means any valid lens can be written like this

@b-mehta
Copy link
Contributor Author

b-mehta commented Aug 7, 2019

Nope: the correct linear rank-1 form of a lens is s ->. (a, b ->. t)

@b-mehta b-mehta force-pushed the two-traversals branch 3 times, most recently from 78ccfa9 to e6d2834 Compare August 12, 2019 18:46
@b-mehta
Copy link
Contributor Author

b-mehta commented Aug 16, 2019

note to self: try having both pwander and dwander in Wandering, and see what breaks: they might not really need to be distinct

@b-mehta
Copy link
Contributor Author

b-mehta commented Apr 1, 2020

@Divesh-Otwani Apologies for leaving this (and other branches) in such a state. Feel free to get in touch with me if you'd like some help tidying it up or just a better idea of what was going through my head with some of the stuff I left unfinished!

@Divesh-Otwani
Copy link
Contributor

@b-mehta Thanks -- will get in touch!

@aspiwack
Copy link
Member

For most of the things introduced here, see #79 . Which covers the same ground except:

  • The traversal story is different there
  • There is no getters with Top

I'm not convinced the getters with Top are much useful at all: after all once you have a linear Top value, then you have to carry it around. You can never get rid of it. Until it is promoted to being unrestricted. So, really, the only use of the Top-based getters would be to define the unrestricted getters, except less efficiently.

I'm leaving the PR open, still, as an inspiration as I'm trying to tackle the traversal story. See also #190 (and soon more).

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