First-class colors (Part 1)

why the other category?

because colors ≠ pen

but pen is the closest primitive category to colors
so pen ~ colors
and other ≠ colors

Why the other category(also the other category is not actually a category, they fall in the variables section(as you can see in the picture below), and dealing with colors is not related to variables.

We could convince @bh and @jens to do it somehow?

welp , that seems bad for our proposal.

I do think we have a higher chance of having this as the devs want snap to be 100% first class

Yeah. I know that.

how are we supposed to use first class colors

untitled script pic-3
This is an example of first class colors, In the simplest case, we could store colors in variables, this could be useful for drawing with pen.
It also makes more sense than
untitled script pic-4
Because it needs a run block to execute.

Edit: Lol @spacer made this a wiki post.
Edit: Yes, I did @helicoptur , you can edit this with more ways to use them.

Can I get some uses for these blocks, I don't want them to just be one of the overlooked libraries of catagorys. I know that they have some potential in them.

Please reply

Depends what you mean. If you have a list of 10,000 colors and want to do something with each of them, then having a real primitive might matter for efficiency reasons. But being able to use the JS Function block in libraries definitely blurs the distinction. The most dramatic example is the Bignum library, which reimplements all the numeric functions, changing the behavior of the actual primitive blocks. (Jens hates that, though.)

Since I reordered the libraries in the menu in 6.1 (I think that was when, too lazy to look it up, 6.something anyway), I personally think about all the ones in the first group as officially primitives. I have a starter project for myself that preloads all of them. I'm thinking of promoting the APL library to that group. When Jens first introduced hyperblocks in 6.0, people were dubious about the complexity of the APL blocks, but since then, Jens has promoted a handful of them to real primitives (e.g. the ones in the menu of the LENGTH OF block). And really I think words and sentences belong in the first group, too, because of our Logo history.

Huh, ok, what do you mean actually by the first group?


Thank You!

Also, Do you think that this would be a good Idea, And do you have any suggestions for out preposition?

The percentages have to add up to 1. In the Panther block, they use a ratio expressed as, e.g., 4:1 to mean four parts of this color to one part of the other color.

By the way, the Panther block, the underlying Scratch capability, and the even more underlying Smalltalk capability all work only for the case in which one of the mixed colors is black or white. Otherwise they get the wrong answer, as I was saying earlier. The reason (I just learned from Jens) is that this color mixing was never meant for users, but rather for shading or tinting the edges of a block for the 3D look. Someday I'll look up what the right formula is for mixing light colors (totally different from mixing paint colors, by the way, so the whole "mix" metaphor is a little strained).

Whoever said that the Colors and Crayons library doesn't make colors first class is correct; it only deals with the pen's color (and so implicitly with the sprite's color if it's a turtle). But it really doesn't require changing Snap! internally to create a first class data type. You just represent it using some existing type, like this:
untitled script pic

The reason for using a list as the type tag rather than just the word "Color" is that this way we can use the IS IDENTICAL TO block to make sure the user doesn't match the tag by accident:

So instead of first class colors, what would help as a primitive feature is first class types, so that a type-tagged list would report False to IS __ A LIST. That would also avoid the need for the global variable to hold the type tag. A printform would also be associated with a new type; for colors it'd be the little square with the color in it. Implementing colors as much as possible in Snap! rather than in JS would be the obvious first test case for first class types. Someday.

Jeez, you guys, this topic is less than a day old, don't be so impatient!

Making colors first class is like making anything first class: You can make a list of them, you can use them as inputs to functions, you can write functions (such as that mix one) that report colors, etc. Think about a game of Mastermind, which is all about colors. When I write Mastermind programs (it's one of my classic things to try in any language that comes along) I stamp colored squares on the stage all the time. (And, by the way, besides a list, another way to represent a color is as a sprite whose costume is a square of that color and whose pen is set to that color. That might be even better!)