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

Higher-kinded ToGraph? #153

Open
michaelpj opened this issue Nov 30, 2018 · 5 comments
Open

Higher-kinded ToGraph? #153

michaelpj opened this issue Nov 30, 2018 · 5 comments

Comments

@michaelpj
Copy link

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 methods ToGraph has.

@snowleopard
Copy link
Owner

snowleopard commented Dec 1, 2018

@michaelpj It's not technically difficult to add a higher-kinded version of ToGraph, but it feels wrong to maintain both versions. The same can be said about Class and HigherKinded.Class: I really would like to get rid of one of them (or both).

I think the main driver would be getting rid of the type family.

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?

@michaelpj
Copy link
Author

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,

@snowleopard
Copy link
Owner

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 United is not parameterised by vertex type at all: it captures only the notions of emptiness, overlaying and connecting things.

@michaelpj
Copy link
Author

Looks nice - although in my case most of the things I'm working on really are very Graph-y, and wouldn't make much sense in a United setting.

@snowleopard
Copy link
Owner

snowleopard commented Dec 14, 2018

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 class United m => Graph m that comes with an additional law abc = ab + ac + bc on top of the laws from United. Then the dilemma (Class vs HigherKinded.Class) will evaporate.

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

No branches or pull requests

2 participants