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

[Ivan Lazar Miljenovic]

Henning Thielemann <schlepptop at henning-thielemann.de> writes:

> Ivan Miljenovic schrieb:
>
>> So you don't want the labels to be part of the actual datatype?  And
>> for users to then have to deal with any labels they want themselves?
>
> No, you would continue to provide labelled and unlabelled graphs, where
> unlabelled graphs (or just Graphs) are the base type and labelled graphs are
>
> data LabelledGraph node edge =
>    LabelledGraph Graph (Map Node node) (Map (Node,Node) edge)
>
> This is a matter of separation of concerns. Sure, it means that you need
> to split the graph algorithms into their parts: each algorithm into an
> unlabelled and a labelled part. If there are algorithms that make no
> sense on labelled graphs, then you need only the first part.

I'm hesitant to do such a thing for the simple reason that it will
involve duplicate work...

It might be possible, by having two classes that do the same thing (Foo
and FooLabelled), but I'm not sure how well this would scale.

>> If so, I don't think this is feasible; some of the nice parts of FGL
>> IMHO are how it deals with labels (admittedly, I've had to write and
>> use my own "((Int,a) -> a') -> g a b -> g a' b" function because it
>> doesn't have one...).  Removing this would be a step backwards.
>> 
>> How exactly is it bad/a pain to have to deal with specifying "g ()
>> ()", especially since there are some pre-defined "unlabelled" graph
>> type and function aliases?
>
> For problems that do not need labels, why shall I cope with them?

Ummm... I fail to see how having labels would make FGL harder to use
just because you have to do "gr () ()" rather than just "gr" in your
types.

> I expect that you quickly run into the need for type extensions,

I was planning on using associated types to state what the node type
was.

> if you define a graph type class that have only unlabelled graphs as
> instance.  For instance:
>
>> instance SpecialGraph (gr () ()) where
>
> is not Haskell 98, instead
>
>> instance (IsUnit a) => SpecialGraph (gr a a) where
>>
>> class IsUnit a where toUnit :: a -> ()
>> instance IsUnit () where toUnit = id
>
> would be Haskell 98, but is certainly more complicated.

Not sure what you're doing here...

But isn't that what newtypes are for?

> This may also answer your question, how hard you should try to stay
> Haskell 98. My experience is, that with a proper design of a library you
> can reduce the need for type extensions. This makes your code more
> portable and easier to understand.

I don't plan on going overboard, but I am not going to go out of my way
to avoid extensions (sane ones; there are no plans on using
IncoherentInstances or something like that!).

Yes, it means that it won't compile on a non-GHC Haskell implementation;
but how many people actually use any other compiler full time?  My
understanding was that the other Haskell compilers still being worked on
(JHC and UHC) didn't fully implement Haskell98 either.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com