Upcoming backward-incompatible changes to `gray` and `mixed`

[Chris Smith]

Hello, everyone.

After a lot of thought, I've come to the conclusion that we need backward-incompatible changes to two color functions in CodeWorld.  This is my announcement of the plan, and how we will proceed.

The `gray` function (and its alternate spelling `grey`) has historically produced a shade of gray, based on an argument in the range from 0 to 1.  This has confused plenty of students, who uniformly believe that "gray" is a color, not a function.  It's particularly confusing when no other colors act in this way.  This unique behavior for gray originated in gloss, but it should really be fixed.  So soon, gray will be a color -- namely: `HSL(0, 0, 1/2)`, an intermediate gray.  Other shades of gray can be produced using the usual transformation functions, such as `light`, `dark`, lighter`, and `darker`, or by constructing the color in a color space, such as `RGB` or `HSL`.

The `mixed` function has historically mixed two colors to produce a color halfway between them.  However, students always want more flexibility than this.  They want to mix colors in different ratios.  They can nest `mixed` functions to make more complex colors, but only when the denominator of all proportions is a power of two, so something as simple as "2 parts brown and one part red" can only be approximated as the limit of an infinite sequence of deeply nested expressions.  To fix this, soon `mixed` will be modified to receive a list of colors as its argument instead of just two colors, and will mix them all in equal proportion.  (A color can be mixed in greater proportions by listing it twice.)  This is easy to use and flexible enough to support what students want without adding much complexity.  As a side benefit, it gives students a way to use lists in a more obvious way than polygons, so that they begin to understand the square bracket notation for a list.

The deprecation schedule here is tricky, because we explicitly need to reuse the same names, but change the types.  There is no way to do this without breaking student code.  So I'll try to find the best time to "rip the bandaid off", metaphorically speaking, but it must be ripped off all at once.  I'll do the following:

1. Immediately, start warning students that their uses of `mixed` and `gray` will change soon.  This change has already been released.  Existing code still compiles, but generates warnings.

2. At some point in between U.S. school terms, make the change.  At the same time, add logic to detect resulting error messages, and rewrite them to explain the backward compatibility issue, and how to adapt the code to fix it.

The sooner we get to step 2, the better, since step 1 leaves us in an awkward spot with unavoidable warnings.  I'm aiming to try to find a sweet spot between the fall and spring terms.  If anyone is teaching and has a range of dates they want me to avoid, please reply and let me know.

Thanks,

Chris

[Chris Smith]

Just a heads-up that I've made these changes.

The only programs that should break entirely right now are those that used `mixed`.  There's a custom error message that clearly explains how to fix them.  Students just need to add brackets, so `mixed(a, b)` is now `mixed([a, b])`.  On top of that, though, the lower-case color names are now deprecated, and give warnings when used.  In their place, we now have a smaller selection of capitalized color names.  Students who previously used the more esoteric colors (like aquamarine and rose) should be encouraged to define their own colors using functions like mixed, RGB, or HSL.

Students using the new capitalized color names can now use them to write specialized equations for functions, such as:

f(Blue) = ...

f(Green) = ...

f(other) = ...

Because the capitalized names are treated as matchable constants rather than variables, this acts like you'd expect.  This is the main reason for the change.