Hi, I think making builtin nested lists is more useful than nested list APIs, and can support any text.
Blocks used (exclude red blocks):

Manipulation of individual items of sublists {
add [] to sublist () of nested list [list v] :: list
delete ( v) from sublist () of nested list[list v] :: list
insert [] at (1 v) in sublist () of nested list [list v] :: list
replace item ( v) of sublist () in nested list [list v] with [thing] :: list
}

Reading of sublists{
reporter (item ( v) of sublist () of nested list [list v] :: list)
reporter (length of sublist () in nested list [list v] :: list)
predicate <sublist () of nested list [ v] contains [thing] ? :: list>
}

Reading of whole nested list {
predicate <any sublist of nested list[ v] contains [thing] ? :: list> 
reporter (sublist count of nested list [list v] :: list)
}

Manipulation of whole sublists {
set sublist () of nested list [list v] to list [ v] :: list
insert list [ v] at () of nested list [list v] :: list
add list [ v] to nested list [list v] :: list
delete sublist () of nested list [list v] :: list
}

Reading whole sublists{
set list [ v] to sublist ( v) of nested list [list v] :: list
}

Uses by itself:
Spritemaps
Databases

Uses with hashtables:
Storing object data

Uses with treemaps:
Part trees

Uses with hash-nested lists:

Support. This will help a lot. Someone said that first level data was banned. However, I do not see it in rejected suggestions.

I support this, but I think simpler way to create a “list in a list” would be to change the output of this block…

(list :: list)

… from a concatenated string (for example, “Apples Bananas Corn”), which is what it does already, to a list…

• Apples
  
• Bananas
  
• Corn
  

…which it what it should do because it is a list. That way, you don't need to create “sublists” with a bunch of new blocks. The current output, a string containing all of the items of the list, could also (or instead) be attained in these formats:

(join (list::list) [])
set [list to string with spaces v] to (join (list::list) using [ ]::operators)

The latter block would also be a nice addition, though.

When Windows crashes::hat events
if <<(desperate) > [50]> and <(Windows) < [0]>> then
go to [Testingsoftware 2.0 v]
say [This is the all-new, next generation Scratch OS]
end
stop [using Windows v]

Testingscratcher wrote:

I support this, but I think simpler way to create a “list in a list” would be to change the output of this block…

(list :: list)

… from a concatenated string (for example, “Apples Bananas Corn”), which is what it does already, to a list…

• Apples
  
• Bananas
  
• Corn
  

…which it what it should do because it is a list. That way, you don't need to create “sublists” with a bunch of new blocks. The current output, a string containing all of the items of the list, could also (or instead) be attained in these formats:

(join (list::list) [])
set [list to string with spaces v] to (join (list::list) using [ ]::operators)

The latter block would also be a nice addition, though.

However, sometimes high performance is required, and processing of strings into list might be too slow

Monniasza_spzoo wrote:

However, sometimes high performance is required, and processing of strings into list might be too slow

I think that largely depends on what kind of load you expect to throw at it. If a list has over one hundred items, and you're trying to stick that whole list into another list, then yea, it might get bogged down, but lists created on most Scratch projects aren't even that massive.

When Windows crashes::hat events
if <<(desperate) > [50]> and <(Windows) < [0]>> then
go to [Testingsoftware 2.0 v]
say [This is the all-new, next generation Scratch OS]
end
stop [using Windows v]

Couldn't you just set up a list to act like an array instead? The list would have an identifier as to what it's storing as the first character(s) in each item, then it would store the info.

codeman1044 wrote:

Couldn't you just set up a list to act like an array instead? The list would have an identifier as to what it's storing as the first character(s) in each item, then it would store the info.

younger kids. They may not understand.

Wouldn't this suggestion be the same complexity as my workaround though?

Some workarounds are presented here https://scratch.mit.edu/discuss/topic/352948/

Keep in mind that not all scratchers would understand that. Would a new scratcher understand what “predicate any sublist of nested list contains thing?” Are there any workarounds for that? Could you find an example where those blocks are useful?

NilsTheBest wrote:

Keep in mind that not all scratchers would understand that. Would a new scratcher understand what “predicate any sublist of nested list contains thing?” Are there any workarounds for that? Could you find an example where those blocks are useful?

Red blocks will not be included. Please exclude any red blocks which appear in the first post.
“any sublist of nested list contains thing?”

<any sublist of nested list [ v] contains [thing] :: list> 

means that at least one item stored within nested list is equal to “thing”.
Possible uses of nested lists:

• Tree structures
  
• Databases
  
• Game operational data
  
• Inventories
  
• Many multiline strings of characters
  
• 3d objects
  
• and many others
  

Testingscratcher wrote:

Monniasza_spzoo wrote:

However, sometimes high performance is required, and processing of strings into list might be too slow

I think that largely depends on what kind of load you expect to throw at it. If a list has over one hundred items, and you're trying to stick that whole list into another list, then yea, it might get bogged down, but lists created on most Scratch projects aren't even that massive.

Some lists are big, which includes game maps.

15-MinuteGaming wrote:

Some workarounds are presented here https://scratch.mit.edu/discuss/topic/352948/

Workarounds will be too slow for real-time games.

codeman1044 wrote:

Wouldn't this suggestion be the same complexity as my workaround though?

Suggestion would be simpler and faster.

Monniasza_spzoo wrote:

Some lists are big, which includes game maps.

“Some are”, which is still analogous to “most aren't”. And of these game maps, in what instances would they require nested lists?

I made paint program in one of my scratch projects, and it uses a list as well, which can grow to tens of thousands of lines sometimes because of the render code I made for it. However, the single list works just fine by itself especially due to recent optimizations, there's rarely any lag and it's completely manageable. I think there's also a list for undo actions, as well as one for simple parameters.

A lot of projects can be made with little issue using existing list functionality. Databases and tree structures, not so much, but at that point you should be directed to Snap! where such advanced functionality is readily available. Scratch is a relatively beginner-oriented location and the blocks that you're suggesting probably wouldn't be easily understood by the school-age children which make up the website's target audience.

When Windows crashes::hat events
if <<(desperate) > [50]> and <(Windows) < [0]>> then
go to [Testingsoftware 2.0 v]
say [This is the all-new, next generation Scratch OS]
end
stop [using Windows v]

Testingscratcher wrote:

Monniasza_spzoo wrote:

Some lists are big, which includes game maps.

“Some are”, which is still analogous to “most aren't”. And of these game maps, in what instances would they require nested lists?

I made paint program in one of my scratch projects, and it uses a list as well, which can grow to tens of thousands of lines sometimes because of the render code I made for it. However, the single list works just fine by itself especially due to recent optimizations, there's rarely any lag and it's completely manageable. I think there's also a list for undo actions, as well as one for simple parameters.

A lot of projects can be made with little issue using existing list functionality. Databases and tree structures, not so much, but at that point you should be directed to Snap! where such advanced functionality is readily available. Scratch is a relatively beginner-oriented location and the blocks that you're suggesting probably wouldn't be easily understood by the school-age children which make up the website's target audience.

Multilevel games and spritemap games require nested lists.

Monniasza_spzoo wrote:

Testingscratcher wrote:

Monniasza_spzoo wrote:

Some lists are big, which includes game maps.

“Some are”, which is still analogous to “most aren't”. And of these game maps, in what instances would they require nested lists?

I made paint program in one of my scratch projects, and it uses a list as well, which can grow to tens of thousands of lines sometimes because of the render code I made for it. However, the single list works just fine by itself especially due to recent optimizations, there's rarely any lag and it's completely manageable. I think there's also a list for undo actions, as well as one for simple parameters.

A lot of projects can be made with little issue using existing list functionality. Databases and tree structures, not so much, but at that point you should be directed to Snap! where such advanced functionality is readily available. Scratch is a relatively beginner-oriented location and the blocks that you're suggesting probably wouldn't be easily understood by the school-age children which make up the website's target audience.

Multilevel games and spritemap games require nested lists.

I would counter by saying that adding nested lists would make it easier, rather than harder. If it is beginner oriented, then why are people forced to come up with such LONG WORKAROUNDS which I stated earlier.


I think this is a duplicate. I will find the link

15-MinuteGaming wrote:

Monniasza_spzoo wrote:

Testingscratcher wrote:

Monniasza_spzoo wrote:

Some lists are big, which includes game maps.

“Some are”, which is still analogous to “most aren't”. And of these game maps, in what instances would they require nested lists?

I made paint program in one of my scratch projects, and it uses a list as well, which can grow to tens of thousands of lines sometimes because of the render code I made for it. However, the single list works just fine by itself especially due to recent optimizations, there's rarely any lag and it's completely manageable. I think there's also a list for undo actions, as well as one for simple parameters.

A lot of projects can be made with little issue using existing list functionality. Databases and tree structures, not so much, but at that point you should be directed to Snap! where such advanced functionality is readily available. Scratch is a relatively beginner-oriented location and the blocks that you're suggesting probably wouldn't be easily understood by the school-age children which make up the website's target audience.

Multilevel games and spritemap games require nested lists.

I would counter by saying that adding nested lists would make it easier, rather than harder. If it is beginner oriented, then why are people forced to come up with such LONG WORKAROUNDS which I stated earlier.


I think this is a duplicate. I will find the link

I will use nested lists in a few games.

15-MinuteGaming wrote:

I would counter by saying that adding nested lists would make it easier, rather than harder. If it is beginner oriented, then why are people forced to come up with such LONG WORKAROUNDS which I stated earlier.

If people on Scratch are forced to use extensive alternatives to achieve a desired result, then, again, maybe they should be using something which is already designed for that purpose. Some things I can agree on: nested lists would be useful to some of us, but redundant to others, and, like I said, confusing for the wanted preteen and early teen users who use the site.

When Windows crashes::hat events
if <<(desperate) > [50]> and <(Windows) < [0]>> then
go to [Testingsoftware 2.0 v]
say [This is the all-new, next generation Scratch OS]
end
stop [using Windows v]

Testingscratcher wrote:

15-MinuteGaming wrote:

I would counter by saying that adding nested lists would make it easier, rather than harder. If it is beginner oriented, then why are people forced to come up with such LONG WORKAROUNDS which I stated earlier.

If people on Scratch are forced to use extensive alternatives to achieve a desired result, then, again, maybe they should be using something which is already designed for that purpose. Some things I can agree on: nested lists would be useful to some of us, but redundant to others, and, like I said, confusing for the wanted preteen and early teen users who use the site.

Added to https://scratch.mit.edu/discuss/topic/212472/