Ivan Lazar Miljenovic wrote:
Heinrich Apfelmus writes:
Yes; what I mean is that you can retrofit a custom vertex type to any
graph implementation that uses a fixed vertex type. So, let's say that
data Gr a b = .. -- graph with vertex type Vertex Gr = Int
then
type Gr' node a b =
Ivan Lazar Miljenovic wrote:
Heinrich Apfelmus writes:
Ivan Lazar Miljenovic wrote:
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
Heinrich Apfelmus apfel...@quantentunnel.de writes:
Yes; what I mean is that you can retrofit a custom vertex type to any
graph implementation that uses a fixed vertex type. So, let's say that
data Gr a b = .. -- graph with vertex type Vertex Gr = Int
then
type Gr' node a b =
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
Heinrich Apfelmus apfel...@quantentunnel.de writes:
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
Neil Brown wrote:
Primarily I want to see in FGL: documentation, documentation and more
documentation.
+1
Cheers
Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
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
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
Ivan Miljenovic wrote:
Heinrich Apfelmus wrote:
Yes, the integers are just indexes. Of course, the example with the even
integers is a bit silly; but if the integers are actually indexes, then
it's conceptually cleaner to make them abstract, i.e.
data Node -- constructors are not
Heinrich Apfelmus apfel...@quantentunnel.de 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
Heinrich Apfelmus schrieb:
Ivan Miljenovic wrote:
I'm not sure I understand what you're saying here: first you said you
wanted to be able to specify a vertex type, now you're saying that you
don't want to know what the vertex type even is (except that it's some
abstract Node type)? Whilst
Henning Thielemann schlepp...@henning-thielemann.de writes:
Heinrich Apfelmus schrieb:
Ivan Miljenovic wrote:
I'm not sure I understand what you're saying here: first you said you
wanted to be able to specify a vertex type, now you're saying that you
don't want to know what the vertex type
Ivan Lazar Miljenovic wrote:
Heinrich Apfelmus writes:
Graphs with different node types don't behave differently; graphs are
parametric with respect to the node type, just like lists don't behave
differently on different element types.
There will be a Map-based graph available that will
On 13 May 2010 17:09, Heinrich Apfelmus apfel...@quantentunnel.de wrote:
Ah, ok, you want graphs that only work with one node type. If there is
at most one such graph for each node type, you could make a data type
family and retain the parameter, though
data family Graph node :: * - *
Heinrich Apfelmus schrieb:
Yes, the integers are just indexes. Of course, the example with the even
integers is a bit silly;
... might be useful for bipartite graphs
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On 13 May 2010 18:14, Henning Thielemann
schlepp...@henning-thielemann.de wrote:
Heinrich Apfelmus schrieb:
Yes, the integers are just indexes. Of course, the example with the even
integers is a bit silly;
... might be useful for bipartite graphs
So, a K_{0,n} bipartite graph? :p
--
Ivan
Ivan Lazar Miljenovic wrote:
Heinrich Apfelmus writes:
I'm not sure what the right solution is, but I think it definitely
involves catering for different node types. For instance, the library
could operate on a type
newtype Graph node a b = Graph (Gr a b, Data.Map.Map Int node)
or it
Henning Thielemann wrote:
Ivan Miljenovic wrote:
You're splitting apart related data into _three_ different data
structures (the graph, vertex labels and edge labels)? _That_ doesn't
make sense.
There are no edge labels, only vertex labels. And yes, I find separation
of data
Heinrich Apfelmus apfel...@quantentunnel.de writes:
Ivan Lazar Miljenovic wrote:
As I said, we're considering using an Associated Type to let users
choose what type they want to use (probably with a default Map instance
for this). However, we'd recommend/push the Int-based one.
For my
Heinrich Apfelmus apfel...@quantentunnel.de writes:
It appears to me that the concerns of labels and vertexes are not
separate enough. After all, the point is that they have to be kept in
sync. Keeping them in sync should be the business of the graph library,
not of the user. It doesn't have
Ivan Lazar Miljenovic wrote:
Henning Thielemann writes:
Recently I wrote cabal-sort using FGL
http://hackage.haskell.org/package/cabal-sort
It sorts cabal packages topologically according to their
dependencies. However, I was neither happy with the way FGL currently
works, nor with the
Heinrich Apfelmus apfel...@quantentunnel.de writes:
I'm not sure what the right solution is, but I think it definitely
involves catering for different node types. For instance, the library
could operate on a type
newtype Graph node a b = Graph (Gr a b, Data.Map.Map Int node)
or it could
On Mon, 10 May 2010, Heinrich Apfelmus wrote:
The nodes are file paths, labeled with a corresponding IO action to
create the file. The nodes are created from a list of rules that specify
how to create an output file from several input files.
That is, in principle you could also use an
On Mon, 10 May 2010, Ivan Lazar Miljenovic wrote:
As I said, we're considering using an Associated Type to let users
choose what type they want to use (probably with a default Map instance
for this). However, we'd recommend/push the Int-based one.
I do not see why there is the need for any
Henning Thielemann lemm...@henning-thielemann.de writes:
On Mon, 10 May 2010, Heinrich Apfelmus wrote:
The nodes are file paths, labeled with a corresponding IO action to
create the file. The nodes are created from a list of rules that specify
how to create an output file from several input
On Tue, 11 May 2010, Ivan Lazar Miljenovic wrote:
Henning Thielemann lemm...@henning-thielemann.de writes:
That is, in principle you could also use an unlabelled graph with
FilePath as node type and you could manage a (Map FilePath (IO ()))
yourselve and FGL does even not know about its
Henning Thielemann lemm...@henning-thielemann.de writes:
On Mon, 10 May 2010, Ivan Lazar Miljenovic wrote:
As I said, we're considering using an Associated Type to let users
choose what type they want to use (probably with a default Map instance
for this). However, we'd recommend/push the
On 11 May 2010 00:08, Henning Thielemann lemm...@henning-thielemann.de wrote:
Because looking up the Map is already very convenient. Why shall I go via
the graph? In the Make example, the graph represents relations between
files. It is not important what particular shell commands must be run
On Tue, 11 May 2010, Ivan Miljenovic wrote:
You're splitting apart related data into _three_ different data
structures (the graph, vertex labels and edge labels)? _That_ doesn't
make sense.
There are no edge labels, only vertex labels. And yes, I find separation
of data structures for
On Tue, 11 May 2010, Ivan Lazar Miljenovic wrote:
Henning Thielemann lemm...@henning-thielemann.de writes:
I do not see why there is the need for any type extension, at
all. Consider cabal-sort, a very basic program, that is Haskell-98
today, will no longer run in Hugs and JHC (untested so
On 11 May 2010 00:22, Henning Thielemann lemm...@henning-thielemann.de wrote:
On Tue, 11 May 2010, Ivan Miljenovic wrote:
You're splitting apart related data into _three_ different data
structures (the graph, vertex labels and edge labels)? _That_ doesn't
make sense.
There are no edge
On 11 May 2010 00:16, Henning Thielemann lemm...@henning-thielemann.de wrote:
On Tue, 11 May 2010, Ivan Lazar Miljenovic wrote:
Henning Thielemann lemm...@henning-thielemann.de writes:
I do not see why there is the need for any type extension, at
all. Consider cabal-sort, a very basic
Ivan Lazar Miljenovic schrieb:
- Having a separate parameter (using associated types?) for the node
type rather than just using Int.
Just Int for nodes was disappointing. It should have been at least a
newtype. I would vote against these experimental features like
associated types or
Christian Maeder christian.mae...@dfki.de writes:
Ivan Lazar Miljenovic schrieb:
- Having a separate parameter (using associated types?) for the node
type rather than just using Int.
Just Int for nodes was disappointing. It should have been at least a
newtype.
This then loses
Ivan Lazar Miljenovic schrieb:
I would vote against these experimental features like associated types
or MPTC and FD. I prefer plain type parameters for data types, but
that does not fit well together with type classes.
Why don't you like extensions? I used to feel the same way, but then
I'm a fan of making FGL more record-based, but definitely keeping the
inductive graph style.
My own biggest gripe with previous versions of FGL was that the graph
implementations were severely underoptimized. In particular, PatriciaTree
left open a *lot* of optimization.
Ivan, would you like to
On 27 April 2010 03:39, Louis Wasserman wasserman.lo...@gmail.com wrote:
I'm a fan of making FGL more record-based, but definitely keeping the
inductive graph style.
Definitely.
My own biggest gripe with previous versions of FGL was that the graph
implementations were severely
37 matches
Mail list logo
