Splitting Up Components

[BebeSparkelSparkel]

There seems to be a lot accumulating in this library. Would it be possible to split out some of the components? I'm willing to help with this

A few good reasons to do this are:

• There are getting to be a lot of dependencies that take a long time to compile
• Your typed Sequences seem very useful outside of this project
• The unused code is making my containers larger and more costly to run
• Modular readers and writers for different geometry file formats like Ipe, DXF, DWG, SVG

I would need some help figuring out where the project should be cut apart at. Here are some places I see right now:

• src/Graphics
• src/Algorithms/{BinaryTree,Graph}
• src/Data/Geometry/Ipe
• src/Data/*Seq.hs
• src/Data/UnBounded
• examples/
• probably a few more

Let me know if this seems reasonable.

[noinia]

Thank you for your interest in hgeometry! It is somehow my hobby-project implementing geometric algorithms/data-structures/things I like, and as you observed it has grown a bit over time. I think splitting it into smaller components definitely makes sense. The following things can easily go into their own packages I think:

• the ipe reading and writing (Data.Geometry.Ipe.*). In the svg branch I also have some similar svg writing modules. Maybe I/we should ressurect the 'hipe' package, and move those modules into hipe again.

• Data.Permutation, Data.PlanarGraph., and Data.PlaneGraph., Algorithms.Graph.* ; these modules implement things having to do with planar/plane graphs, and having them separate would make sense.

• Some of the non-geometric types, like the Sequence types, Data.Ext, Data.UnBounded, Data.Range, Data.BinaryTree etc. (and maybe the corresponding Algorithms.BinaryTree.* modules), the OrdSeq modules etc. Somehow, I don't think these modules would be "big enough" by themselves to go into individual packages.

This would leave the geometric data types, the geometric algorithms, and the examples and benchmarks etc. I'm ok with moving the examples into a separate package, but having them behind a flag (like currently is the case) seems fine to me to. I don't feel strongly about either of those options. We could split the package further (i.e. algorithms and data types separately), but I do think there are some cross-dependencies that would be somewhat annoying to untangle.

Would something like that satisfy your use-case(s)? Furthermore, any suggestions for naming the sub-packages are welcome ;)

[BebeSparkelSparkel]

I'm just going to start with extracting ipe. It would be nice to have a family of packages that are obviously related would hgeometry-ipe be an acceptable name?

[noinia]

As you may have seen I've split the package into several subpackages. There are still some small things that I want to fix, and I have to update some documentation (readme etc). All of the actual geometric data structures and algorithms are still in the main "hgeometry" package. As I've indicated before, I'm not sure if/how to split this further because of cross dependencies between the data types and algorithms. Any further suggestions are welcome of course :)

[BebeSparkelSparkel]

Ok, I will examine your splits and let you know if I have any suggestions

[noinia]

Done, so I'm closing this.