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

Redo Enter #736

Merged
merged 2 commits into from May 5, 2017

Conversation

Projects
None yet
3 participants
@phadej
Copy link
Member

phadej commented Apr 28, 2017

"Fixes" #734

@fizruk

This comment has been minimized.

Copy link
Member

fizruk commented Apr 28, 2017

Nice!

Can we also add some custom TypeErrors here?
Otherwise I except there to be some unreadable type errors.

Can we interpret Enter as a closed function (type-level to term-level) and disallow any other instances (filling the holes with custom type errors)?

@phadej

This comment has been minimized.

Copy link
Member Author

phadej commented Apr 28, 2017

I guess we can drop the ret from Enter definition; and have a TypeError in Entered.
Via constraints the GHC should be able to reason "back" ret -> typ anyway.

@alpmestan

This comment has been minimized.

Copy link
Contributor

alpmestan commented Apr 28, 2017

I still think Nat is the wrong thing to use there. Enter should really just be about walking down :<|>-separated stuffs, idealy. But +1 as this improves on the status quo.

@fizruk

This comment has been minimized.

Copy link
Member

fizruk commented Apr 28, 2017

@alpmestan where's the prior discussion about :~> and why we generalised over it?
Can you link it here?

@phadej

This comment has been minimized.

Copy link
Member Author

phadej commented Apr 28, 2017

I guess it may work with generic transform, not m :~> n, but then we have to specify that it can be inverted (that what enter's functional dependencies force us to do). Not sure how the lack of injectivity (if we don't' want to specify the inverse) would work.

@alpmestan

This comment has been minimized.

Copy link
Contributor

alpmestan commented Apr 28, 2017

@alpmestan where's the prior discussion about :~> and why we generalised over it?
Can you link it here?

@fizruk I'm not sure there ever was a discussion about generalizing the kind of transformation we can apply, as the original motivation for Enter was to go from a monad to another. It's just been on my personal wishlist for years. I think Enter should allow us to apply any transformation "that can be applied on the given chain of :<|>-separated stuffs", whatever those :<|>-separated stuffs are. I ideally would like a solution such that "if the types align, we should be able to do it". But I don't want to block this PR on that, just using the occasion to maybe pull you guys down that rabbit hole with me =)

@phadej

This comment has been minimized.

Copy link
Member Author

phadej commented Apr 28, 2017

@alpmestan in this case we have to fuse old Enter with m :~> n so we can more specifically write
"if you have typ api, you'll get ret api". We could use defunctionalization to make Enter generic, but that is far from elegant (IMHO).

@phadej phadej added this to the 0.11 milestone Apr 29, 2017

@phadej

This comment has been minimized.

Copy link
Member Author

phadej commented Apr 29, 2017

@fizruk how urgent this is for you; I'd like to release 0.11 only after ZuriHac + few weeks; as then there
might be other major stuff in (e.g. Lenient params)

@fizruk

This comment has been minimized.

Copy link
Member

fizruk commented Apr 29, 2017

@phadej not urgent, I have a workaround in place for now.

@phadej phadej merged commit d004805 into haskell-servant:master May 5, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@phadej phadej deleted the phadej:entered branch May 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.