[Haskell-cafe] Re: What do _you_ want to see in FGL?

[Heinrich Apfelmus]

Ivan Lazar Miljenovic wrote:
> Heinrich Apfelmus writes:
>>
>> 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
>> ? [..]
> 
> 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.

Ah, that would indeed make it easy. Maybe make the map based graph
generic, so that it can be used with any primitive graph implementation?

   data VertexGraph node gr a b = VG (gr a b) (BiMap node (Vertex gr))

   instance (Ord node, Graph gr) => Graph VertexGraph node gr where

But this is probably not worth the hassle because if you really want
performance, you shouldn't choose another  gr  but rather make your own
instance with a custom map. I think it's fine to supply a default choice
for  gr .

>> 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.

That would be much appreciated. :)


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com