color does not enforce refinements

[schanzer]

The Color library includes the color constructor, whose documentation says the first three inputs should all be numbers between 0-255 (inclusive). However, calling the function with numbers outside of that range seems to work just fine.

This is either a bug in the implementation or the documentation. I'm inclined to say the implementation should conform to the documentation.

[asolove]

Currently, I think color is defined as a plain data constructor with no refinements on the values allowed:

data Color:
  | color(
      red :: Number,
      green :: Number,
      blue :: Number,
      alpha :: Number)
end

-- https://github.com/brownplt/code.pyret.org/blob/horizon/src/web/arr/trove/color.arr#L9

and then code that interprets colors is clamping the RGB values when it interprets them.

---

If we want to make the runtime behavior match the docs, and throw an error when the values are outside of bounds, then we can add a refinement check on the color constructor. I'll make a PR for that, though it has some possible impacts it's hard for me to guess.

[blerner]

Neither. We discussed this a long time ago: there is potential mathematical value in having denormalized numbers. (If we ever wanted to do an optics-related unit, say, where we wanted to understand additive color, then we'd like to say "red + yellow = yellow", because even though you have more red than before you can't see it, it's too bright. Similarly subtractive color should allow for negative values, that get clamped to zero analogously.) We stuck with the documentation as is for now, so that only highly-exploratory students might encounter it; otherwise, it would be moot.

[schanzer]

@blerner whoa - that is a really interesting explanation. I don't think any teacher who doesn't already know you and Joe would ever think of that. Could we add that to the documentation, and then close this issue?