I moved my lecture series on how lists work here:
Hey, @hekknyt
You should definitely read Brian's thread to understand how lists in Snap! work 
For a quick start however, this might help:
Snap!'s list block is a reporter (ovally shaped block that reports a value and can be used as an input to other blocks (e.g. the item _ of _).
If you want to use the add block to add stuff to a list programmatically, you have to create a variable.
As the add block requires a list as its second input, you have to take care that your variable is set to a list first.
This script doesn't work, because the variable my list is not of the list type.
If you initialize the list first, by setting the variable my list to an empty list, it works:
Of course you can not only use the command block add to extend your list, but also the function in front of, e.g. like this:
However, as Brian mentioned, you shouldn't combine those 2 ways of dealing with lists, because the internal representation of these lists is different (linked list vs. array) whether you use the in front of block or the add block and you might want to avoid converting between two data types all the time.
Hope that helps,
cheers,
jadga
My crazy idea would be, and I know you will not like it, but I am going to say it anyway. When the "ADD something TO Foo" command is used, it should automatically set the Foo variable to list type so the user doesn't necessary need to do it by previously SET-ting it to list type.
yeah, but the user's intention can be very ambiguous. What if the variable already has a value? Should we throw it away or treat is as the first item of a coerced list? And, thinking this even further, what if it's not a variable but the item of another list? Should we then silently turn the target list into a multi-dimensional one? I think this opens up pandora's box...
Can you, perhaps, make lists separate from variables, like scratch does? That would make it more straightforward for everyone.
We are talking newbies here, remember (I know it is your job as an experienced developer to take into account all possible scenarios, and I do appreciate it), and not many newbies are expected to be aware of the possibility of ADD-ing an item_of_another_list TO an_existing_list, let alone to try to do it. Or they wouldn't be newbies.
This capacity of the ADD to silently modify Foo type to list type would only be reserved for the cases meeting two criteria:
- the value_to_be_ADDed is either a plain text or a plain number (turning into an item in the process) and
- the target variable was not defined (i.e. SET to) as a list type yet.
heck no! That would totally defeat the purpose of teaching the idea of variables and first-class-ness.
I don't think so, because it is the purpose of Snap' to teach users that you can make a variable to point to various things, not only plain text or numbers, but also more complicated stuff, for example, a ringified (snippet of a) script (or block), an object (sprite) (if I am not mistaken), a list, etc.
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.