-
Notifications
You must be signed in to change notification settings - Fork 67
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
Higher-kinded ToGraph
?
#153
Comments
@michaelpj It's not technically difficult to add a higher-kinded version of
Could you expand this bit? Type families were introduced just for this very purpose: creating type classes for various collections (well, at least this one the main example using in papers on type families). They do require an extra extension and sometimes complicate the type inference, but isn't this an appropriate price for being able to handle not fully parametric instances? |
I for one find it much easier to work with type parameters wherever I can. It feels strange to be using a type family when you are in fact parametric. I guess I am probably biased by not caring so much about the non-parametric instances at the moment, |
I've published a (rather long) blog post about one more type class that we might want to consider when working with algebraic graphs: https://blogs.ncl.ac.uk/andreymokhov/united-monoids/ The type class |
Looks nice - although in my case most of the things I'm working on really are very |
What I meant to say is: perhaps we can switch to a graph type class that is not parameterised by the type of vertex, something like |
Seems like there are much the same considerations as for #9. Again, I think the main driver would be getting rid of the type family.
We could have both, as we do for the
Graph
classes, but this is a bit annoying because of how many methodsToGraph
has.The text was updated successfully, but these errors were encountered: