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

Modular Types with Higher Kinds #98

Open
wants to merge 21 commits into
base: master
Choose a base branch
from
Open

Modular Types with Higher Kinds #98

wants to merge 21 commits into from

Conversation

gmalecha
Copy link
Owner

@gmalecha gmalecha commented Dec 4, 2016

This is an extension to @mmalvarez's work on core types that includes support for higher kinds, e.g. you have a deep embedding of types that are not of sort Type.

For example, there is a representation of option rather than option T for some T. This makes it possible to implement more sophisticated structures, e.g. functors, applicatives, and monads, that can not be represented in without higher-order types.

Note: Not yet ready to merge.

@gmalecha gmalecha self-assigned this Dec 4, 2016
@gmalecha
Copy link
Owner Author

gmalecha commented Dec 4, 2016

I'm thinking that I will leave in CTypes for the time being even though its implementation is morally equivalent to Types.FTypes. The CTypes implementation might be faster because the kind language is implicit. The downside of this is that because it doesn't match up with the interface, I will have to resurrect a bunch of code.

@gmalecha
Copy link
Owner Author

gmalecha commented Dec 4, 2016

@jesper-bengtson We should see if theories/Types/FTypes.v (this is morally the same as the old modular types) or theories/Types/HTypes.v (this includes higher kinds) will work better. I believe with the current code that you are working on FTypes will probably be sufficient, though automating something like Applicative might be easier with HTypes.

@gmalecha
Copy link
Owner Author

gmalecha commented Dec 4, 2016

@mmalvarez would you be up for doing a code review before this gets merged?

@gmalecha
Copy link
Owner Author

The library code is done, but the interface is not very usable without patterns. Unfortunately, this is just an aspect of Coq usability, dependent pattern matching does not have good enough heuristics.

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.

1 participant