I think that we should allow a list of lists.
This can allow people to have categories of items, or other things. There are many ways that it can help benefit.

READ BEFORE SAYING NO SUPPORT: It is possible to make code to imitate this. But, for some users, it is too complex. Scratch is made to be a simple coding language. Also, having many scripts can cause lag on some platforms.

Hmm. It appears that the list scratchblock isn't working.

So something like

? This would make lists first-class, however could make things more complicated. Support since adding that one block I made in the example would give us the ability for lists in lists in lists….

No support, I know it's complicated, but Scratch isn't supposed to be filled with cheap workarounds for complicated stuff. It's supposed to allow users to learn and progress in their Scratching skills as they confront new problems. If you come across something with a complicated workaround, learn how that workaround works. Learning that workaround may teach you new things you never knew Scratch could do and greatly progress your Scratching skills.

Heh, kinda reminds me of when I made a suggestion because I wanted lists in lists but the workaround would be too slow for the speed I wanted my project to run at…
I tried to avoid first class lists, but come close by rather using the string representation of the list that the list reporters give out. Here's the thread.

wow
much support
so useful
implement scratch team pretty please

DaSpudLord wrote:

No support, I know it's complicated, but Scratch isn't supposed to be filled with cheap workarounds for complicated stuff. It's supposed to allow users to learn and progress in their Scratching skills as they confront new problems. If you come across something with a complicated workaround, learn how that workaround works. Learning that workaround may teach you new things you never knew Scratch could do and greatly progress your Scratching skills.

Although I agree that there shouldn't be ten thousand blocks for things that have easy workarounds, I disagree that this should count as one of those things. Multi-dimensional lists are really common in other programming languages, and sometimes the workaround isn't convenient. At all.
For example, you might end up making multiple lists which clutters up the data area, could result in excess programming and makes things seem daunting for Scratchers that may want to look at how you made it. If you use the letter (x) of item (y) of (list) workaround, you can only have one letter for an item in the list. Ow. Another workaround is to have all the items of a 2d list in a list, and access an item with equations involving the width and length of the 2d list.
Adding this wouldn't discourage Scratchers to come up with workarounds (I mean, they're probably not going to remove the numbers-only rule for cloud data or add in psychics blocks any time soon). It would encourage Scratchers to make more advanced things with more advanced features, which would in turn improve your Scratching skills.

Support for first-class lists.

DaSpudLord wrote:

No support, I know it's complicated, but Scratch isn't supposed to be filled with cheap workarounds for complicated stuff. It's supposed to allow users to learn and progress in their Scratching skills as they confront new problems. If you come across something with a complicated workaround, learn how that workaround works. Learning that workaround may teach you new things you never knew Scratch could do and greatly progress your Scratching skills.

Thanks for pointing this out, it is true. I suggested this because most things that you can do would be really hard for New Scratchers. Also, because more blocks can mean more lag.

bobthemonkey0 wrote:

DaSpudLord wrote:

No support, I know it's complicated, but Scratch isn't supposed to be filled with cheap workarounds for complicated stuff. It's supposed to allow users to learn and progress in their Scratching skills as they confront new problems. If you come across something with a complicated workaround, learn how that workaround works. Learning that workaround may teach you new things you never knew Scratch could do and greatly progress your Scratching skills.

Thanks for pointing this out, it is true. I suggested this because most things that you can do would be really hard for New Scratchers. Also, because more blocks can mean more lag.

Yeah but it is a huge feature of text-based programming languages. Also, lambda FTW.

CatsUnited wrote:

So something like

? This would make lists first-class, however could make things more complicated. Support since adding that one block I made in the example would give us the ability for lists in lists in lists….

No Support Because You Can Easily Do That.

picklehazard wrote:

CatsUnited wrote:

So something like

? This would make lists first-class, however could make things more complicated. Support since adding that one block I made in the example would give us the ability for lists in lists in lists….

No Support Because You Can Easily Do That.

The workaround is tedious and sometimes uneconomical.

Prinseskat wrote:

Although I agree that there shouldn't be ten thousand blocks for things that have easy workarounds, I disagree that this should count as one of those things. Multi-dimensional lists are really common in other programming languages, and sometimes the workaround isn't convenient. At all.

CatsUnited wrote:

bobthemonkey0 wrote:

DaSpudLord wrote:

No support, I know it's complicated, but Scratch isn't supposed to be filled with cheap workarounds for complicated stuff. It's supposed to allow users to learn and progress in their Scratching skills as they confront new problems. If you come across something with a complicated workaround, learn how that workaround works. Learning that workaround may teach you new things you never knew Scratch could do and greatly progress your Scratching skills.

Thanks for pointing this out, it is true. I suggested this because most things that you can do would be really hard for New Scratchers. Also, because more blocks can mean more lag.

Yeah but it is a huge feature of text-based programming languages. Also, lambda FTW.

Many programming languages make nesting a lot easier than Scratch, even though Scratch is meant to be a simple language. Scratch needs to add something for nesting at some point.

While I think a list within a list would be a great way to store 3D data,
I think it may complicate things too quickly.

I'd be happy if you could just reference the list name with a variable.

Then you could accomplish a similar task by referencing
which list you are trying to access, simply by changing the variable.

X would be the row number, Y would be the column,
and Z would be the name of the list.

This would be a great method to illustrate color mixing,
because you could put red along the X, green along the Y
and blue along the Z, then ping-pong up and down the lists
for whatever mixable madness you desire.

Doyousketch2 wrote:

-snip-

But that requires JSON hacking - do you know a workaround that uses Vanilla Scratch, no edits from external editors?

CatsUnited wrote:

Doyousketch2 wrote:

-snip-

But that requires JSON hacking - do you know a workaround that uses Vanilla Scratch, no edits from external editors?

Only to set the list; the workaround showed above can be workarounded with Vanilla Scratch.

CatsUnited wrote:

But that requires JSON hacking - do you know a workaround that uses Vanilla Scratch, no edits from external editors?

As it is, no. You have to set up separate lists for each Z slice,
then do whatever routine you want with each list individually.
So for the above, you'd have to do:

All the way up to the 16th list, for that particular example.

So every script you do, you'd have to redo, for every layer
that you plan to use in your project.

Doyousketch2 wrote:

CatsUnited wrote:

But that requires JSON hacking - do you know a workaround that uses Vanilla Scratch, no edits from external editors?

As it is, no. You have to set up separate lists for each Z slice,
then do whatever routine you want with each list individually.
So for the above, you'd have to do:

All the way up to the 16th list, for that particular example.

So every script you do, you'd have to redo, for every layer
that you plan to use in your project.

Yeah but you have to create 16 lists, which can get annoying.

There are many ways to workaround this, depending on the number of lists that you want-

You can have a single list, and each row represents an entire row on the list. The columns are separated by a single predefined character (for example, I like to use an asterisk). For example, this is what the list might look like-
Apples*Pears*Bananas
Cars*Trucks*Planes

You can have 3 lists. On the first list, the x locations of each item are stored. On the second list, the y locations of each item are stored. On the third list, the value of the slot is stored. For example, this is what the lists might look like-
List 1: List 2: List 3:
1 1 Apples
1 2 Pears
1 3 Bananas
2 1 Cars
2 2 Trucks
2 3 Planes
You could also combine list 1 and 2 to create a set of coordinates separated by a comma, decreasing the number of lists required to 2.

You can have a single list. Each row is represented by multiple slots on the list. To separate rows, a special string is inserted into one of the items on the list. For example, this is what the list might look like-
Apples
Pears
Bananas
<split>
Cars
Trucks
Planes

DaSpudLord wrote:

There are many ways to workaround this, depending on the number of lists that you want-

You can have a single list, and each row represents an entire row on the list. The columns are separated by a single predefined character (for example, I like to use an asterisk). For example, this is what the list might look like-
Apples*Pears*Bananas
Cars*Trucks*Planes

The problem with this is, to obtain an item from there you'd first need to separate the list up, which requires more lists and variables. If you want to compare items of the same 2d list, you'd need to save the first item in a variable, which means more and more random variables and lists floating around that you have to manage… Also, what happens if you try to have an item that contains the separator? It'll assume it's a new item and cause bugs.

You can have 3 lists. On the first list, the x locations of each item are stored. On the second list, the y locations of each item are stored. On the third list, the value of the slot is stored. For example, this is what the lists might look like-
List 1: List 2: List 3:
1 1 Apples
1 2 Pears
1 3 Bananas
2 1 Cars
2 2 Trucks
2 3 Planes
You could also combine list 1 and 2 to create a set of coordinates separated by a comma, decreasing the number of lists required to 2.

I don't see much point in this one. Three times the amount of lists required, and you'd have to find what item is the correct x or y of the respective list before finding the item, again using more variables. (Really, in some projects I have about 20 variables simply because of this sort of thing. It's annoying, especially since we can't have script-only variables.) Combining the x and y lists means you'd have to separate each item of the list until you find the right item, which is again just inconvenient and could slow things down if trying to find an item in a large list.

You can have a single list. Each row is represented by multiple slots on the list. To separate rows, a special string is inserted into one of the items on the list. For example, this is what the list might look like-
Apples
Pears
Bananas
<split>
Cars
Trucks
Planes

This isn't so bad, but again if the item that splits the rows is used as an item bugs could occur. Also requires a variable to go through the list unless it's got a fixed size, in which you can forget about the item that splits them and find an item by (((y+1)*columns)+x)… this isn't perfect as you can only have a 2d list with exactly this amount of columns and that amount of rows instead of a list in a list in a list, which could give you 3d lists and other awesome things.

Maybe I sound lazy by saying the workarounds are really annoying, but they really are annoying. Just because you can mess around with a bunch of variables and lists and illogical things trying to accomplish something doesn't mean that there shouldn't be an easier way to do it. Otherwise, why do we have lists when you could just make ten thousand variables (though I'm pretty sure 50% of things involving lists would become impossible) or custom blocks when you could just broadcast things or clones when you could make a few more sprites or the “move n steps” when you could use trigonometry?