Heinrich Apfelmus <apfel...@quantentunnel.de> writes: > Ivan Lazar Miljenovic wrote: >> Heinrich Apfelmus writes: >>> I'd be happy with either one. :) In both cases, I want to specify a >>> custom vertex type. >> >> Except an abstract type isn't a custom vertex type... >> >>> I can either do that directly if the library permits, though I think the >>> solution with associated types is too cumbersome to be useful for my >>> make example. >> >> Why? > > I was under the impression that I would have to define a new graph data > type with FilePath as vertex type and make that an instance of Graph > ? In that case, it would be much shorter for me to stick with the clumsy > > nodeMap = Map.fromList nodes > index k = Map.findIndex k nodeMap > nodes' = map (\(a,b) -> (index a, b)) nodes > edges' = map (\(a,b,c) -> (index a, index b, c)) edges
Well, we'll provide a Map-based one that lets you specify the vertex type as a type parameter; this functionality (type parameter being ued for the vertex type) won't be required since not all graphs will be able to chop and choose which vertex type to use. > In the make example, I didn't need to get a node based on its label > either. But the graph was a graph of FilePaths and I still have to > implement an association between that and Int . (In fact, I don't know > of any graph whose nodes are unique integers conceptually.) > > In other words, I have to make sure that every FilePath is mapped to a > unique integer which I can then glue into a graph. This is not hard to > do with a Data.Map and the four lines of code above do exactly that. > However, I still had to think about it and it took me way too long to > come up with these four lines. What I would like to see is that the > *library* has thought about that for me already. Right; I'm going to look at merging this import-like functionality from Graphalyze (which already does this). > [snip] > > To summarize: an abstract Node type relieves me from thinking about > the association between my conceptual node type and unique identifiers. > I'd be happy with anything along these lines, the interface above is > just a suggestion. Well, you can consider the current Int vertex type to be a (not-so-) abstract vertex type; it might be an idea to wrap this up so people don't mess with it themselves though. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe