yeah, but see, special cases like these ("reserved for the cases meeting two criteria") only make some things easier on the surface, while introducing a lot more complexity to remember. So you'll think you're learning something but in reality you're just memorizing special cases designed to trick you into using a particular feature. Snap is about having fun with computer science, so we want to find good ways to let you explore the Big Ideas, and - at least - real CS - and that includes getting to know variables for what they are, not merely placeholders for "plain text" or "plain number" etc. It's getting used to that kind of thinking that makes it appear to use something like lists. Once you realize that a list is just a thing, and that a variable is just a placeholder for a thing, you've actually learned something about CS, not just something about Java.
Of course, I agree with you (see above my reply to hekknyt).
Still, you want to make the road to that knowledge gentler and smoother. This is the rationale behind my proposal, not to invent special cases but to smooth the road.
Exactly! What is a smoother way to learn this knowledge than having been playing with the ADD block and finding out that, wow, my (target) variable (despite having no idea it can do it) can be a placeholder for a list of letters/numbers, and in the next step I can discover that it can also be a placeholder for many more exciting things such as ringified stuff.
Because in this scenario when I am a newbie, maybe I didn't even expect it to happen, when I experimented with the ADD block, I just tried and added a word to an empty variable and, wow, I learned the word has magically turned into an item of a list (that was created silently by the ADD block).
Now I know this is possible, and the road to all sorts of list knowledge is open.
add a dropdown menu to the list boolean so the user can choose what they intend.
I'm kind of lost in this recent conversation because I don't understand what "set the variable to list type" means. Do you mean "replace the value X with the value (list x)"? Because variables don't have types. They just have values, and those have types. So it doesn't make sense to talk about "SETting Foo to list type."
One thing Scratch does wrong, imho, is try to make everything meaningful, so as to avoid at all costs giving an error message. So for example you can use "23skidoo" as input to an arithmetic operator, and it'll just use the 23, That's okay if you're just trying to get something on the stage any old how. It's okay if you're timid and an error message will make you never try again. But it makes debugging a lot harder. If I try to ADD something to a non-list, what I want is an error message. A friendly, helpful one, but an error message.
I'm also starting to get confused, this is a post I made a few days ago and it already has 25 replies, this being the 26th. this post has gotten really sidetracked.
oh, and "list type" just means the variable has been turned into a list and can now be referred to as a list.
I'm not sure I understand this, but I think you're still thinking in Scratch terms, in which lists are sort of parallel to variables. They both have names and values, but a variable has one value and a list has a bunch of values.
But that's not how it works in 
. A list is a value. One value, no matter how many items are in the list. The value 47 doesn't have a name, and neither does the value (781 47 99).
Variables have names. Their job is to associate a name with a value. (Fine print: The real truth is that the job of a variable is to associate a name with a location in memory. You can put any (one) value you like (including a list) into that location in memory, using SET. I knew that that was the official story, but never understood why until we invented upvars. You don't have to worry about it.)
So "the variable has been turned into a list" doesn't mean anything. It's like, I don't know, "the pumpkin has been turned into happily"; it doesn't mean anything because "happily" doesn't fit into that slot in a sentence.
You can assign a list value to a variable, same as any other value. But you can't just declare that 42 is a list. Like it or not, 42 is a number.
if the pumpkin is happy,
the variable is listlike.
:~/ :~/
stupid forum won't let me post unless there are words.
Yes, now it is much more clear - it would be really helpful if you could put it under the C) chapter titled "Functional and Imperative List Programming" of the Manual.
I apologize for making no sense by saying "set the variable to list type". So, let me try to explain what I am saying in practical - not theoretical terms.
So - when I open a new project in and I press "create a variable" button and I name the variable "foo", you are saying - at least in theory - my new variable has no type - "because variables don't have types (t)hey just have values, and those have types" - but, practically speaking, it does have a type, ok, I should say "its value has a type", and I practically see that it was silently (i.e. "by default") SET to 0 despite all my intentions.
Now, because of this I am forced to SET my new variable to "an ('anonymous') list value" first in order to be able to do what I intended - i.e. ADD an item to it. Well, of course, you will say, because it was already SET to 0 and I may reply simply by saying, "Oh, no, it was not - at least I didn't SET it to anything (yet)!"
On one hand, I'm practically allowed to use some blocks immediately (such as "CHANGE it BY ..."), i.e. without being forced to "SET it TO" an ('anonymous') text value (or an ('anonymous') number value) first.
But, on the other hand, I can not immediately "ADD item to...", i.e. without being forced to "SET it TO an ('anonymous') list value" first.
This is what is bothering me.
I think you replied to the wrong person.
Yes, it might be better if variables were created with an initial value of *uninitialized* or something. In my own programming, if I want a variable to have 0 as its starting value, I SET it to 0 even though I know I don't have to. One of the common bugs in Scratch is that a project works the first time you run it but not the second time, because some global variable has a nonzero value and the code assumes it starts at zero.
But I'm afraid we're stuck with starting at 0 because by now there are about seventy bazillion projects that depend on that behavior. Also, in particular, Jens's "block variables" feature has no way to give a block variable an explicit starting value, so you end up doing
in the code that you run every time the block is called.
But, all that aside, imho you're not doing yourself a favor by thinking of variables as having types. There's nothing stopping you assigning values of different types to the same variable at different points in your program. Just for example, FIND FIRST applied to a list of numbers will report either a number or False, so if you use that in your program you can't just blithely do arithmetic on that value.
Rereading this: I wouldn't say "it's already set to 0." I'd say "you haven't given it a value, so why do you expect it to have a type?" Yes, it's really zero, but that's a misfeature. Think of new variables as type-virgin, and your life will be richer and more peaceful.
please stop replying to this topic
But actually, this is what i'm thinking:
:~/<p>
ALWAYS PUT A P TAG AFTER YOUR POST!!!