Editing Diagrams/Dev/Constraints (section)

== Why a type family in -lib rather than a polymorphic V2 type? ==
* The real person you would have to ask that question is byorgey. He wrote the V type family: https://github.com/diagrams/diagrams-core/blob/75e7f64caa7d0bd6e384bd5316b6e5e6754b1f1d/src/Graphics/Rendering/Diagrams/V.hs. He also used the Scalar type from vector: https://github.com/diagrams/diagrams-core/blob/75e7f64caa7d0bd6e384bd5316b6e5e6754b1f1d/src/Graphics/Rendering/Diagrams/Points.hs#L59. All I did was propagate that idiom into all of diagrams-lib. Indeed, I recommended not using Scalar in https://github.com/diagrams/diagrams-core/pull/65, and that has been looked at with suspicion. So the type families are here to stay.
* The question that could be asked, however, is:
=== Why not simply parameterize over the scalar value and fix our two-dimensional vector type to be V2? ===
* The existing datatype was packed, and I though that should be preserved (and indeed it is, in Diagrams.TwoD.Types.Double). That was what I put in my proposal (or its comments, rather), and so that was what I implemented. It wasn't really any effort, since there was already a type family (V) to use. The diagrams types are already highly polymorphic, so adding more polymorphism shouldn't hurt (much).
* Later, someone told me on IRC that the packed datatype wasn't that useful. Although the type family does let R2 be packed, it doesn't let us pack the other data types, such as SizeSpec2D.  Looking at libraries such as vector and text, it seems that the general approach for packing types is to create a data family of packed types, create marshaling/unmarshalling functions, and then optimise them out (a process known as "fusion"). If we go the fusion route, then the packed R2 types are unnecessary (the data family takes care of them) and so all we need is V2. Terminology note: since e.g. String -> ByteString is called 'pack', "packed" datatypes are those that use unboxed types. This might appear to conflict with current GHC terminology which uses the UNPACK pragma to signify unboxing. However, the opposite of UNPACK is NOUNPACK, not PACK, so they are technically not in conflict. I suggest removing the "UN" part so that the pragmas are PACK and NOPACK respectively.
* Suppose we did change out the parameters of v for parameters of s and change the usages of v to usages of (V2 s). The V type family will remain in use for other reasons, such as abstracting over 2D vs 3D, so now the library has different API's for 2D, 3D, and generic code. But it already did (generic vs. R2Ish vs. R2Ish). The (R2Ish v) constraints change  to (ScalarIsh (V s)) constraints. But writing them over and over again is boring, so we define R2Ish again. Except this time, since V2 / V3 are in the types already, we can actually just define RIsh (no dimension). So all that actually needs to change are the data types and the constraint synonym name.
* So now I'm thinking it's possible and useful to just always use V2. In particular, I can't write the generic Renderable instance unless all types have the same scalar type parameter as their last type argument, which using V2 uniformly makes easy but using V makes hard.

=== What is R2Ish other than R2? ===
* I have Float and Generic (V2) modules in my branch. R2 is  Double-specific,  Float.R2 is float-specific, and SDouble's are ADT's (boxed types), thus don't pack, so the generic V2 is sufficient.
* It also turns out that the R2Basis :>: a type (defined for HasTrie R2Basis) is R2Ish, although I didn't write the instances. In fact, we could just define type V2 a = R2Basis :>: a. I'm not certain this gets us anything besides some accessors (untrie f XB and untrie f YB for accessing x/y components resp. of V2). We already have Coordinates and HasBasis though, so IMO not much point in it.
=== Why does V2 then pop up in diagrams-constraints? ===
* V2 shows up in diagrams-constraints because it uses boxed types. Similarly, R2 shows up in diagrams-svg because it uses Doubles. Etc.