Editing Diagrams/Dev/Constraints (section)

== What are some next steps to make diagrams-constraint useful? (ideally a bunch of small, specific tasks) ==
The main things is rewriting diagrams-core to be friendlier to constraints
* byorgey has the fixed-point branch
* new NamedPrim constructor so primitives can use/output names - could be useful for e.g. <a name="..."> in SVG as well as for constraint stuff
* adjustments to Attributes; they should use lenses rather than Data, and just be pure Scalar v's instead of Measure's. Measures can be done by replacing the number data type (similar to what I do in diagrams-constraints with CDouble - basically, you stack backends instead of hacking in special cases like Measure). Of course, the constraint solver copes just fine with things like "the diagram's width is the sum of the widths of these circles, and each circle's width is 1/x of the diagram's width", while Measure probably does not, but I don't think it will be any worse than what we have now.
* Handle traces (which currently output a SortedList, requiring Ord) better. Haskell lists don't translate to sbv nicely, so maybe add a new datatype TraceResult with firstIntercept/lastIntercept methods (removing SortedList). I'd have to check the usage, but I think we can get away with just those two in most of diagrams-lib...
* After that, write the generic Renderable instance as above and the constraints backend will be very low-maintenance (updating only with sbv or with diagrams-core).
* Some more tasks would be some "nice" primitives for simple objects such as rectangles, which are much easier for constraint solvers to deal with than general paths. In particular, the current diagrams-lib API means that all circles must be rendered first to Path's, losing information (and also adding an Ord constraint since the discretization process is numerical). Ideally, the backends would do the discretization and Arc would be a rendering primitive rather than a function that returns a path (arcT). Or we could add conic sections as Segments, and just generalize our notion of "Path".