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

Hi Conal,

I think what sent me down this path in the first place is that you had already defined a `Monoid` instance for `Color` in module `Shady.Color` with definition

```haskell
instance Monoid Color where
mempty = clear
mappend = overC
```

This means it is true that `toColor mempty == clear` and also that `toColor (a `mappend` b) == toColor a `mappend` toColor b`.

Can you expand on your remark "I don't think of `toColor` that way, because we can distinguish between values that toColor identifies". I'm not sure I fully understand.

I don't mind your idea of adding a `preClear` method to `HasColor`. The reason I wanted this in the first place can be seen in my definition of the `ShadyGeometry` data type in module `Shady.CompileEffect`. The `shadyImage` field of the record has type `Image c`. I define a smart constructor that provides sensible defaults for a `ShadyGeometry` value

```haskell
shadyGeometry :: ShadyGeometry Color
shadyGeometry = ShadyGeometry {
shadyImage = const $ clear,
shadySurface = xyPlane }
```

I actually wanted this smart constructor to be polymorphic and have the definition be:

```haskell
shadyGeometry :: HasColor c => ShadyGeometry c
shadyGeometry = ShadyGeometry {
shadyImage = const $ mempty,
shadySurface = xyPlane }
```

Now that I revisit this code, I really feel it should be the polymorphic version and I wonder why I made the type more specific. In the polymorphic definition it would suffice for us to have `preClear` here instead.

Incidentally, why did you call it `preClear`?