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

set order comparison #5

Open
joeyh opened this Issue Mar 17, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@joeyh

joeyh commented Mar 17, 2016

While sets are not ordered, type signatures need list items in a specific order, or the type checker will complain.

Eg, Set '[Natural 0, Natural 1] vs Set '[Natural 1, Natural 0]

Your examples suggest to leave off the type signatures and let them be inferred, sidestepping this problem. Which is fine, but in my application, the content of the set is important documentation, so I'd rather include type signatures.

I don't know if this is fixable with current ghc's Data.Type.Equality

@dorchard

This comment has been minimized.

Show comment
Hide comment
@dorchard

dorchard May 27, 2016

Owner

Hi! Yes, the examples tend to rely on inferring the types, but you can use the AsMap type-level function to do the normalisation for you in a type signature. See for example, foo' in https://github.com/dorchard/type-level-sets/blob/master/example.hs. So you can include the type signature, but you don't have to normalise yourself. Does this help?

Owner

dorchard commented May 27, 2016

Hi! Yes, the examples tend to rely on inferring the types, but you can use the AsMap type-level function to do the normalisation for you in a type signature. See for example, foo' in https://github.com/dorchard/type-level-sets/blob/master/example.hs. So you can include the type signature, but you don't have to normalise yourself. Does this help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment