reverseTrail should not generate extra segments for closed trails

[fryguybob]

(Imported from http://code.google.com/p/diagrams/issues/detail?id=50. Original issue from byor...@gmail.com on September 6, 2011, 08:53:32 PM UTC)

For reference, see this darcs log message:

Fri Aug 19 10:05:25 EDT 2011 Brent Yorgey <byorgey@cis.upenn.edu>

• fix bug in reverseTrail: should not delete first segment, it might be a Bezier!
  reverseTrail has the unfortunate property that it adds a segment every time it is called,
  since it must insert the "implicit" segment at the end, even if it is essentially Linear (0,0)
  (or, more likely, Linear with two very small nonzero values, due to imprecision). This means
  that reverseTrail is not actually self-inverse, although it will probably LOOK like it is.
  I wonder whether we ought to explicitly store the final segment of a closed trail.

I think it would actually be better to stop trying so hard to maintain the same "base point" for closed trails. That is, when reversing a closed trail, the new base point should be the endpoint of the last explicit segment, exactly the same as if we were reversing an open trail. This might be a bit unintuitive but given that we store the closing segment implicitly it's really the only way to do things properly, so that we get laws such as reverseTrail . reverseTrail = id.

Perhaps we should also add a function 'completeTrail' (or something to that effect) which turns the implicit segment of a closed trail into an explicit segment. That way you could always get the behavior you might otherwise expect from reverseTrail on a closed trail by first calling completeTrail. Of course, it seems like completeTrail ought to be idempotent but that would not be the case for the obvious implementation.

Perhaps instead of a Boolean indicating an implicit closure we ought to have something like

data Closed v = Open | LClosed | BClosed v v

where (BClosed c1 c2) indicates closing the path with a Bezier segment with control points c1 and c2, and an implicit endpoint.

[byorgey]

Fixed via @705a9b2889c92267300b33e53bb4e13be3d65c9c.