Anton Felix Lorenzen
Anton Felix Lorenzen
> Please try various different approaches and let us know how they work! The more I think about this, the less sure I am that there should be a representation...
> Note that it is in principle possible to define an algebra of graphs, which operates on ordered vertices, From a first glance at the laws, it looks like this...
This seems to be a special case of partial orders: Those that are induced by a total order on keys (Extension in your example). But in general, transitivity could be...
Have you looked into [doctest](https://github.com/sol/doctest)? I think it would go a long way towards reducing code duplication.
> with some higher-level combinators. Absolutely, but why should they be in `Graph`? An algorithm working on graphs would have to consider all of them and there would be no...
> A more efficient approach would be to have a function toAdjacencyMap :: Graph a -> AdjacencyMap a that avoids unnecessary computation and performs an optimised compilation of the given...
> This instance doesn't allow to share common subgraphs and is therefore typically very slow. I don't see why this is a problem, isn't not sharing subgraphs the default for...
> Take the AdjacencyMap instance: you have a lot of sharing between various subgraphs within the same expression. Ah, sharing while constructing the graph and not in the fully evaluated...
Duplicate of #149 (but better title, I guess)
@bracevac I was just looking at this and realized it was still unsolved. Even the reformulation: ``` co type stream { SCons(hd: a, tl: stream) } fun hist_helper(s: stream, state:...