Henning Thielemann writes:
> Ivan Lazar Miljenovic schrieb:
>
>> Pros for allowing you to use a custom node type:
>> * Matches your data better
>> * No need for extra lookup maps when converting your data to FGL form
>>
>> Cons:
>> * Makes type-sigs uglier/more verbose
>
> Unlabelled graphs with
Ivan Lazar Miljenovic schrieb:
> Pros for allowing you to use a custom node type:
> * Matches your data better
> * No need for extra lookup maps when converting your data to FGL form
>
> Cons:
> * Makes type-sigs uglier/more verbose
Unlabelled graphs with custom node type would have only one typ
Henning Thielemann writes:
> On Wed, 28 Apr 2010, Ivan Miljenovic wrote:
>
>> 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?
>
> Recently I wrote cabal-sort using FGL
> http://hackage.haskell.org/packa
On Wed, 28 Apr 2010, Ivan Miljenovic wrote:
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?
Recently I wrote cabal-sort using FGL
http://hackage.haskell.org/package/cabal-sort
It sorts cabal packages
Henning Thielemann 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 (
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 l
On 28 April 2010 08:48, Henning Thielemann
wrote:
> Ivan Lazar Miljenovic schrieb:
>> Henning Thielemann writes:
>>> I was not happy with the way FGL handles lables so far:
>>> http://www.haskell.org/pipermail/libraries/2008-February/009241.html
>>
>> Not sure I follow what you want there: you
Ivan Lazar Miljenovic schrieb:
> Henning Thielemann writes:
>> I was not happy with the way FGL handles lables so far:
>> http://www.haskell.org/pipermail/libraries/2008-February/009241.html
>
> Not sure I follow what you want there: you want to remove the whole
> concept of labels and replace
Henning Thielemann writes:
> I was not happy with the way FGL handles lables so far:
> http://www.haskell.org/pipermail/libraries/2008-February/009241.html
Not sure I follow what you want there: you want to remove the whole
concept of labels and replace it with the node type? What about edge
l
Ivan Lazar Miljenovic schrieb:
> Since I've volunteered myself to help maintain/upgrade FGL, what do the
> people in the community want to see happen with it?
I was not happy with the way FGL handles lables so far:
http://www.haskell.org/pipermail/libraries/2008-February/009241.html
___
Stephen Tetley writes:
> What would your thoughts be on freezing FGL as it is and putting
> changes into a new package "FGL2" or "NewFGL"?
That's another possibility. However, I was planning on keeping the
fundamental layout and design of FGL. I quite like and have used the
inductive approach o
Hello Ivan
What would your thoughts be on freezing FGL as it is and putting
changes into a new package "FGL2" or "NewFGL"?
The implementation technique for FGL is independently interesting;
Martin Erwig expanded on it in other papers ('Metamorphic
Programming') but no one else seems to have picke
Hi,
Primarily I want to see in FGL: documentation, documentation and more
documentation. The library has lots of undocumented functions
(especially the queries, e.g.
http://hackage.haskell.org/packages/archive/fgl/5.4.2.2/doc/html/Data-Graph-Inductive-Query-DFS.html
has no documentation at a
Since I've volunteered myself to help maintain/upgrade FGL, what do the
people in the community want to see happen with it?
Here are some ideas that I have regarding FGL:
* I had already started working on a new generic graph class [1] (with
initial draft at [2]) to act as a wrapper around FGL
14 matches
Mail list logo
