sseefried/shady-graphics — comment on commit fc12faff3d1acb31fcef1a4d9316ab0d6ed34e50
File:  line 0
By conal:

Hi Sean. Sorry I added to the confusion with the wording of my remark about `Any`. I was trying to point out exactly what you mentioned about `False`/`(||)` being only one of the possible choices of `Bool` monoid (together with Haskell requiring at most one instance per type) as a reason to use `newtype` wrappers like `Any` and `All` for their `Monoid` instances and have no instance for `Bool`. So I'd expect similar wrappers on `Exp Bool`.

In my last "BTW", I was checking my assumption that you'd added a `Monoid BoolE` instance, since I figured it must be there and I hadn't noticed it yet.

I think what you're trying to accomplish is `toColor mempty == clear`. Since for colors, `mempty == clear`, we might entertain the idea of wanting `toColor` to be a monoid morphism wherever it's defined, implying not only `toColor mempty == clear` but also the additional property that ``toColor (a `mappend` b) == toColor a `mappend` toColor b``. I don't think this `HasColor`/`Monoid` link had occurred to me, and I don't know what would motivate this particular TCM. I always want semantic functions to be TCMs, but I don't think of `toColor` that way, because we can distingish between values that `toColor` identifies. As a way into and through this question, we could look for other `HasColor` instances and see what they have to say. One is gray-scale.

If we really want a general way to talk about values mapped to `clear` by `toColor`, and the `Monoid` connection doesn't turn out to be a natural (unforced) fit, then we could add a `HasColor` method. Something like `preClear` with a class law that `toColor preClear == clear`. What leads you to want such a thing?