-
Notifications
You must be signed in to change notification settings - Fork 68
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
Semigroup version of Algebra.Graph.Labelled.AdjacencyMap #307
Comments
How are you planning to use |
I think if you look at the code you'll find that you can use
If you make This is because, unlike Another way to say this is that in the Going back to how I plan to use this: I want to be able to use the |
Oh, I see! I didn't realise that you were suggesting to remove Now it all makes sense. Interesting. I was always thinking of One problem with just removing |
Yes! I'm honestly not sure what to do either. Even though the semigroup version seems more general, it is subtly wrong when The best option I came up with is to do something like what's done in containers with, e.g., |
Could you point me to an example? |
In I imagined one could do something similar with this library. I don't know that this library needs a module like module Algebra.Graph.Labelled.AdjacencyMap.Semigroup (...) where
-- We can import and reuse the `AdjacencyMap` type itself as well as functions like
-- `empty`, `vertexSet`, `hasEdge`, and many others that don't rely on the `Monoid e` instance.
import Algebra.Graph.Labelled.AdjacencyMap (...)
-- For functions where the signature changes, we redefine them
overlay :: (Semigroup e, Ord a) => AdjacencyMap e a -> AdjacencyMap e a -> AdjacencyMap e a
overlay (AM x) (AM y) = AM $ Map.unionWith (<>) x y
... In this way, there would certainly be a new module, but it wouldn't be a full duplicate of the existing one -- it would only include new code. Furthermore, the type The biggest problem with this approach, which is also a problem in But, I mean, if |
I see, thank you for the detailed explanation! What you suggest is certainly doable in practice but at the same time, it doesn't feel right. It's also expensive in terms of maintenance, and I'm not sure I'm ready to sign up to support this sort of thing. As I mentioned, I actually plan to go in the opposite direction and remove a few modules instead of adding new ones, because the library is already too bulky and confusing. From all the discussed options, I'm leaning towards just dropping |
I was looking into using this library (and the
Algebra.Graph.Labelled.AdjacencyMap
module in particular), but the edge type I want to use is not aMonoid
, only aSemigroup
. Indeed, one of the things I like aboutLabelled.AdjacencyMap
is that the adjacencies are stored sparsely, i.e., that non-existent edges are not stored, which makes a lot of sense for me because there is no value in my edge type that represents not-an-edge.If I'm understanding the code correctly, it looks like
mempty
(orzero
) of the edge monoid is only used to filterzero
edges out of the adjacency map. I'm not proposing you drop theMonoid
constraint -- for edge types that do have azero
element, filtering it out makes sense -- but it seems to me there could be a parallel module for labeled adjacency maps that only uses aSemigroup
constraint and never filters.P.S. Also, I understand that I could wrap my edge type in
Maybe
and, because the labeledAdjacencyMap
never storeszero
edges, unwrap with something likefromJust
every time I view an edge. I find this unsatisfying.The text was updated successfully, but these errors were encountered: