Table of Contents
1. Description
2. Argument on why it should be accepted.
2.1. The importance of it in Scratch.
2.2. The difficulty and limitations of the workarounds.
3. Possible workarounds.
3.1. Cloning.
3.2. Strings.
4. Arguments against it.
4.1. The potential to cause lag.
4.2. That scratch is supposed to be simple.
5. Rebuttal and ways to address issues.
5.1. Presence of lag, data limit, and possible list limit.
5.2. Creating a list is not complex. The workaround is more complex.

1. Description
The suggestion is to create a block which simply creates a list with no no entries.. It would look much like this.

Create list [name ]

Lists created in a program are to be deleted when the program ends to prevent lag. Normal list operations can be done to this list, like adding items, inserting, and others.

2. Arguments on why this suggestion should be accepted.
2.1. Importance of creating a list.
Lists are an important part of scratch when you want to do major programs, as they are dynamic, in order, and simply allow you to store variables in one place. One of the important parts about lists is that they are dynamic, meaning that you can store variables in them, and you can change the amount of items. However, sometimes, dynamic nested lists are required, in which you change the amount of lists you are adding into one list. This will be useful in a program in which one is keeping track of multiple characters, each with different properties, and characters spawn every so often, and characters can change their properties. In this, with the absence of OOP, because of the need to keep scratch simple, dynamic nested lists is the simplest way to do it. It can also be used in a variety of different kinds of projects, which adds to their appeal, from a text analysis project to a game.
2.2. Difficulty and limitations of Workarounds
There are some workarounds to this problem. However, these workarounds are quite complex and have some limitations. The two main ways are using cloning and using strings. The cloning way clones a sprite, cloning a local list, and then places that local list in the global list. Some limitations to this are that one can only have up to 301 list entries, and that clones cause lag. The strings way creates a string which splits the entries by a symbol, often a comma or a slash. The limitation to this is that one cannot use that splitting symbol in any of the list entries, or else it will malfunction.

3. Workarounds
3.1. Cloning
As stated earlier, the cloning method starts with a main sprite with a list in it and a global list. When the list needs updating, it creates a clone and feeds the information which is needed for the list to a clone with the clone id (a variable which clones are assigned based on when they are created) of the index which needs to be added. Then the clone list is placed in the global list. This can be hard to code due to the clone id variable being broadcast and the adding of clones and lists. It can also be laggy due to the number of clones.
3.2. Strings
As stated earlier, the string system splits items with a character. This can be seen here.

define change to list (string)
set [List v] to ((join (join [!] (string)) [!]))

define Add to list (value)
set [Counter2 v] to [1]
set [Counter v] to []
repeat ((length of [(list)]) - (1))
set [Counter v] to (join [(counter)] (letter (counter2) of [(list)]))
change [Counter2 v] by (1)
end
set [Counter v] to (join (join [Counter] [(value)]) [!])
set [list v] to [counter]
set [Counter v] to []
set [Counter2 v] to [1]

define Item of list (number)
set [Counter3 v] to [1]
set [Counter4 v] to [1]
set [Counter5 v] to [1]
set [Counter6 v] to [0]
set [Output v] to []
repeat until <not <[Counter5] = [1]>>
if <(letter (Counter3) of [list]) = [/]> then
change [Counter4 v] by (1)
end
if <(Counter4) = (number)> then
set [Counter5 v] to (Counter3)
end
end
set [Counter5 v] to ((Counter5) + (1))
repeat until <(Counter6) = [1]>
if <(letter (Counter6) of [list]) = [;]> then 
set [Counter6 v] to [1]
else
set [Output v] to (join (output) (letter (Counter5) of [list]))
end
change [Counter5 v] by (1)
end

WARNING, CODE MAY HAVE BUGS OR MAY NOT WORK CORRECTLY! THIS IS JUST TO DEMONSTRATE HOW IT MAY WORK! I AM A NEW SCRATCHER AND AM NEW TO SCRATCH AND SCRATCHBLOCKS
The other methods of lists, like insert and delete, employ similar methods, including string operations.

4. Arguments against it
4.1. Potential to cause lag.
Lists, because they contain a large amount of data, can cause lag when automated.
4.2. Scratch principles
Scratch is supposed to be a challenge, and people should not be just given blocks. They should instead use the workaround. Also, scratch should be a simple language, and nested loops are not simple.
4.3. Lists used in string/number operations.
Lists may be used in a join block or an addition/subtraction block, causing problems. This is because lists may be in the same list as other things like strings as numbers.
5. Rebuttal/ways to address
5.1. Presence of lag, data limit, and possible list limit.
There is already a large amount of lag on scratch because of clones and effects. This would not have too significant an impact in it. Its impact is reduced with Scratch’s limit of data per project. A limit of the amount of lists could be added if it is that large a problem. Lists are also to be deleted after program ends.
5.2. Examples of ways when stuff were made simple and the complexity of workaround
Scratch is not just for the challenge. Why else would the glide block be added? Or the move block? Also, the workaround is not only difficult, but also has limitations. About the other argument, nested loops are relatively simple compared to the workaround.
5.3. Suggestion of type of () block
The only way to avoid number/string/list problems can be to have a block which tells the type of, with its possible outputs being . This is important because it would be useful, not only for the list problems stated earlier, but also for existing number/string problems. This would give a string output which would be either “number,” “string,” or “list.” It would look like this.

(type of [] :: operators) 

Thank you for reading!

Having a couple of lists with their values constantly being changed is not enough to cause lag.

Even if it did cause lag, the existence of a dormant list (one where the values are not being changed) would not add anything to it.

Script-defined lists are really dodgy anyway- you have to check when the list is created or deleted. If it gets created at the start of the project, it doesn't really need to be defined. It could just be created manually. If it gets created in the middle of the project, then it's up to you to make sure the list is only called after creation and not a second before.

Yeah, as with defining variables in the code itself, there isn't much need for this. I recommend using up values on existing lifts than creating new ones.

However, I disagree with the second paragraph. Broadcasting can be used after the list is created, preventing the list from being called before it is created. Please explain about the part of workarounding lists as list items in more detail. Thank you.

You missed what I consider to be the best and most useful workaround. If the nested lists have a constant length, it is very easy to implement, can have any characters a normal list can have, and isn't slow or laggy like the two workarounds you mentioned.

Say you have 2 lists which you want to store in a list: [1, 2, 3, 4] and [6, 7, 8, 9]. Since these are both 4 items long, you can store them as 1 list like so: [1, 2, 3, 4, 6, 7, 8, 9]. You can do this infinitely so long as you don't run past the 200,000 list item limit.

define get (item #) of (list #)
set [item v] to (item ((item #) + ((list #) * (4))) of [list v] :: list) // 4 is the length of a list

define set (item #) of (list #) to [value]
replace item ((item #) + ((list #) * (4))) of [list v] with (value) // list # starts at 0, item # at 1

bump

I guess you'll also want to be able to drop a reporter which reports the name of a list into the list dropdowns, as in Panther? (Edit: Oh, sorry, that was suggested by the second paragraph. First class lists would let you store lists in other lists rather than just their names.)

Support, this would make my projectes great again

Bump

staffordboys wrote:

Support, this would make my projectes great again

Please, don't advertise your projects!

100daysummer wrote:

staffordboys wrote:

Support, this would make my projectes great again

Please, don't advertise your projects!

@staffordboys is not exactly advertising in their post, because they are simply saying that their projects contain lists and/or OOP, which would benefit from a “create list” block. If you are talking about the advertisement underneath his post, advertising in forum signatures is allowed, as shown here.

15-MinuteGaming wrote:

100daysummer wrote:

staffordboys wrote:

Support, this would make my projectes great again

Please, don't advertise your projects!

@staffordboys is not exactly advertising in their post, because they are simply saying that their projects contain lists and/or OOP, which would benefit from a “create list” block. If you are talking about the advertisement underneath his post, advertising in forum signatures is allowed, as shown here.

Ok.

But you can create a list in scratch so im not sure what you mean….

No. He means that you can use blocks to create lists:

create list [whatever_name v] :: list

And

delete list [whatever_name v] :: list

I'll only support if this applies to variables, too.

ResExsention wrote:

No. He means that you can use blocks to create lists:

create list [whatever_name v] :: list

And

delete list [whatever_name v] :: list

I'll only support if this applies to variables, too.

Technically a variable is a block…. I just dont understand what would be different if it was nor a variable block

Bump

No support. why would you use this? you can use local lists and make clones. then you can make the clone read that list content to another list if requested, very simple. also, I see no uses for this ;-;

JackK211424 wrote:

No support. why would you use this? you can use local lists and make clones. then you can make the clone read that list content to another list if requested, very simple. also, I see no uses for this ;-;

You can only have 301 lists then…

15-MinuteGaming wrote:

JackK211424 wrote:

No support. why would you use this? you can use local lists and make clones. then you can make the clone read that list content to another list if requested, very simple. also, I see no uses for this ;-;

You can only have 301 lists then…

The workaround I suggested still works perfectly fine though and is easy to implement once you know what you are doing.

imfh wrote:

You missed what I consider to be the best and most useful workaround. If the nested lists have a constant length, it is very easy to implement, can have any characters a normal list can have, and isn't slow or laggy like the two workarounds you mentioned.

Say you have 2 lists which you want to store in a list: [1, 2, 3, 4] and [6, 7, 8, 9]. Since these are both 4 items long, you can store them as 1 list like so: [1, 2, 3, 4, 6, 7, 8, 9]. You can do this infinitely so long as you don't run past the 200,000 list item limit.

define get (item #) of (list #)
set [item v] to (item ((item #) + ((list #) * (4))) of [list v] :: list) // 4 is the length of a list

define set (item #) of (list #) to [value]
replace item ((item #) + ((list #) * (4))) of [list v] with (value) // list # starts at 0, item # at 1

However, it has the limitation that lists must be the exact same size…

15-MinuteGaming wrote:

JackK211424 wrote:

No support. why would you use this? you can use local lists and make clones. then you can make the clone read that list content to another list if requested, very simple. also, I see no uses for this ;-;

You can only have 301 lists then…

uhh, why would you need more then that? XD