[diagrams] Attributes

[Ryan Yates]

It would be useful for some attributes to be subject to some
transformations.  As an example lets consider line width.  I think there are
two straight forward ways that line width can be represented:

    A) Have the value constant and represent the line width of the final
diagram.
    B) Have the value scale with the diagram.

Given line widths of option A we can think of scaling as manipulating the
diagram or redrawing it on a bigger piece of paper.  With option B we can
think of scaling as changing the view or moving the "camera" closer or
further away.  It would also be useful to have a function that (for lack of
a better term right now) I'll call !freeze :

    freeze :: Diagram b -> Diagram b

This would turn all the attributes of type A and turn them into ones of type
B.  Back to the camera analogy it would be like taking a snapshot and
treating the snapshot as the new diagram.  It seems natural that if we have
a freeze that we could have a "thaw" too, but I'm not sure I can think of a
good situation where we would want to "thaw".  Perhaps if we could
selectively pick which attributes to freeze and thaw the situations where we
would want to do that would become apparent.

In another direction, are the two options (A and B) just two points in a
continuum of ways to treat attributes?  In the case of line width A is a
constant scaling and B can be determined by the relationship between the
bounds when the attribute is first applied and the bounds when the diagram
is rendered (or "frozen").  Maybe then the generalization of B is:

    newtype B = B (AttributeClass a => Bounds b -> Bounds b -> a)

or perhaps:

    newtype B = B (AttributeClass a => Diagram b -> Diagram b -> a)

which would lead to:

    mkDependentAttribute :: (AttributeClass a) => a -> (a -> Diagram b ->
Diagram b -> a) -> B

    scalingLineWidth :: LineWidth -> Diagram b -> Diagram b -> LineWidth
    scalingLineWidth (LineWidth w) original new = LineWidth (w * ratio)
        where ratio = ... -- in terms of original and new.

Both options for the general B seem to be too general and harder to
implement than requiring AttributeClass to be Transformable (or similar).
 So are there any uses that would require this sort of deep dependence that
do make sense?

Anyway, just some thoughts to start off the conversation,

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.haskell.org/pipermail/diagrams/attachments/20101116/1abf8cce/attachment.htm