(variable1)

set [variable2 v] to (variable1)

(example list :: list)

Something appears to be missing here...

set [  v] to [] :: list 

set [list 2 v] to (list 1 :: list) :: list

set [list 2 v] to [list 1 v] :: list

set [list 2 v] to (list 1 :: list) :: list
set [list 2 v] to (some list data) :: list
set [list 2 v] to [flashlight crowbar classified-documents] :: list //list contents become "flashlight", "crowbar", "classified-documents"
add (list 1 :: list) to [list 2 v] //lists in lists!
set [tmp v] to (item (1 v) of [list2  v]) :: list //retrieve the list in the list
define i haz list inputz!!11 [list1]
set [tmp v] to (list1) :: list

• Strings could have a whole new meaning. You could set a list to a string so the letters or words get separated from each other. In fact, every string can now be considered a list, similar to how strings work in languages like C, but better. If you had the string “hello”, then if you wanted to remove a letter, you could load it into a list and remove and add letters anywhere! If you had the string “hello world”, loading it into a list would separate each word, which can be removed or added, plus each element, single words, can be a list in itself as mentioned before!

• Real two-dimensional lists/lists in lists could finally be made. Currently, this problem is worked around by using a two dimensional array; It has a fixed number of elements, and the element at (x, y) is accessed using (x * total columns + y). A two dimensional list would be able to grow and shrink in both dimensions; it does not have a fixed size. This would be done by making the elements of one list the string representation of other lists!

• Lists could be passed through custom block parameters! Because passing lists around as strings would have a bunch of new purposes, lists could be passed into custom blocks through string parameters, and the string could be loaded into a second list that the custom block uses to do its function. Who knows what Scratchers will do with that ability.

define set (List1) to (List2)
delete (all v) of (List1)
repeat (length of (List2)
add (item ((length of (List1) + (1)) of (List2)) to (List1)
end
end

DaSpudLord wrote:

No support.

define set (List1) to (List2)
delete (all v) of (List1)
repeat (length of (List2)
add (item ((length of (List1) + (1)) of (List2)) to (List1 :: lists) :: lists
end

DaSpudLord wrote:

define set (List1) to (List2)
delete (all v) of (List1)
repeat (length of (List2)
add (item ((length of (List1)) + (1)) of [List2 v]) to [List1 v]
end

Znapi wrote:

Before someone says it, I know that you can get around this by running through each element of one list and adding it to a second list. That is like running through each letter in a variable and adding it to the end of a second variable. It is slower than just setting one equal to the other.

Znapi wrote:

DaSpudLord wrote:

define set (List1) to (List2)
delete (all v) of (List1)
repeat (length of (List2)
add (item ((length of (List1)) + (1)) of [List2 v]) to [List1 v]
end

Thanks, I was writing this from my tablet and was kinda in a rush, so I had a couple problems.

DaSpudLord wrote:

DaSpudLord wrote:

No support.

define set (List1) to (List2)
delete (all v) of (List1)
repeat (length of (List2)
add (item ((length of (List1)) + (1)) of (List2)) to (List1)
end

Whoops… fixed it.

DaSpudLord wrote:

define set (List1) to (List2)
delete (all v) of (List1)
repeat (length of (List2)
add (item ((length of (List1)) + (1)) of (List2)) to (List1)
end

add () to list [ v] () times :: list

FalconGunner99 wrote:

DaSpudLord wrote:

define set (List1) to (List2)
delete (all v) of (List1)
repeat (length of (List2)
add (item ((length of (List1)) + (1)) of (List2)) to (List1)
end

I think we all know that that is too complicated to be a reasonable workaround for newer scratchers.

I support, some better list blocks would be great.

I also think a

add () to list [ v] () times :: list

block could be nice, although it is much easier that the other blocks to work around.

define add (String) to (List) (Times) times
repeat (Times)
add (String) to (List)

replace item (1 v) of [list v] with []

(list :: list)

set [ v] to () ::list

set [ v] to [ v] ::list

JoeyTheChicken wrote:

Well, the thing here is that

(list :: list)

blocks and anything else return a value. Even booleans return values, just true and false. While you can get the value of a list by clicking the above block, it stops making actual sense once you try to implement it for any reason. Because of this nature, throwing a list reporter in
here:

set [ v] to () ::list

would stop making sense very quickly, because that's all you could do with it. Put in any other value and you stop making sense. Set list to 9 makes no sense. While I understand how much sense

set [ v] to [ v] ::list

seems to make, well, it would be so much easier if we were allowed to add dropdowns to custom blocks.

Also, when would you really need that? It wouldn't be useful all that often. Besides, you can't have everything done yourself I personally think the workaround is really cool. And Scratchers have to learn to work within limits, and not having that block is one of them. As was said in an awesome article I once read, paraphrased because my memory is in no way adamant, “I like limits. Limits force us to come up with new ideas to break boundaries.” So yeah I think we should leave it as it is. What we should have is those custom dropdowns.

DaSpudLord wrote:

Also, how would the string be separated into separate items in a list? Or would it only fill a single item in the list? If so, then which item in the list would it fill? The reason we don't have this is because a list is a variable with multiple slots for numbers/strings. Instead, we have

replace item (1 v) of [list v] with []

You can't just set a list to a single value because it can have MULTIPLE values.

(list :: list)

Znapi wrote:

It takes a string and uses it to set the contents of a list. Each element is separated by spaces, like the current list reporter reports.

Znapi wrote:

When a lists has multiple elements that contain spaces words, you can no longer tell where each element starts and stops with the string reported by the current reporter block.

JoeyTheChicken wrote:

Well, the thing here is that

(list :: list)

blocks and anything else return a value. Even booleans return values, just true and false. While you can get the value of a list by clicking the above block, it stops making actual sense once you try to implement it for any reason. Because of this nature, throwing a list reporter in
here:

set [ v] to () ::list

would stop making sense very quickly, because that's all you could do with it. Put in any other value and you stop making sense. Set list to 9 makes no sense. While I understand how much sense

set [ v] to [ v] ::list

seems to make, well, it would be so much easier if we were allowed to add dropdowns to custom blocks.

Also, when would you really need that? It wouldn't be useful all that often. Besides, you can't have everything done yourself I personally think the workaround is really cool. And Scratchers have to learn to work within limits, and not having that block is one of them. As was said in an awesome article I once read, paraphrased because my memory is in no way adamant, “I like limits. Limits force us to come up with new ideas to break boundaries.” So yeah I think we should leave it as it is. What we should have is those custom dropdowns.

Znapi wrote:

JoeyTheChicken wrote:

Well, the thing here is that

(list :: list)

blocks and anything else return a value. Even booleans return values, just true and false. While you can get the value of a list by clicking the above block, it stops making actual sense once you try to implement it for any reason. Because of this nature, throwing a list reporter in
here:

set [ v] to () ::list

would stop making sense very quickly, because that's all you could do with it. Put in any other value and you stop making sense. Set list to 9 makes no sense. While I understand how much sense

set [ v] to [ v] ::list

seems to make, well, it would be so much easier if we were allowed to add dropdowns to custom blocks.

Also, when would you really need that? It wouldn't be useful all that often. Besides, you can't have everything done yourself I personally think the workaround is really cool. And Scratchers have to learn to work within limits, and not having that block is one of them. As was said in an awesome article I once read, paraphrased because my memory is in no way adamant, “I like limits. Limits force us to come up with new ideas to break boundaries.” So yeah I think we should leave it as it is. What we should have is those custom dropdowns.

I had a feeling I wan't clear enough. The reporter block will continue to report a string of all of the elements of the list separated by spaces like it currently does. The format of the string input the simple one the reporter uses, and many Scratchers are familiar with it already. So, setting a list to “9” would mean that the list will contain one element that equals “9”.
I agree that the second block is a little useless, partly just an idea I came up with while working on the post. The idea from that came from changing the reporter to report some non-scratchly actionscript data type would not fit with Scratch and an algorithm programmed in Scratch would not be able to modify it. It would end up being like the second block; it set the actionscript contents array of one list directly to the contents array of the other.

add [] to [  v]
add [] to [  v]
add [] to [  v]
add [] to [  v]

JoeyTheChicken wrote:

I see where you're coming from and what you mean, but I actually thought the second block was better. The first one really just doesn't make much sense. You could sit and type all of it into one string, but the block would be the same as

add [] to [  v]
add [] to [  v]
add [] to [  v]
add [] to [  v]

several times. That's why the second block made more sense, but it still just doesn't sound that important or necessary. As I said, you can't have everything done for you.

Znapi wrote:

JoeyTheChicken wrote:

I see where you're coming from and what you mean, but I actually thought the second block was better. The first one really just doesn't make much sense. You could sit and type all of it into one string, but the block would be the same as

add [] to [  v]
add [] to [  v]
add [] to [  v]
add [] to [  v]

several times. That's why the second block made more sense, but it still just doesn't sound that important or necessary. As I said, you can't have everything done for you.

It is has uses for slightly more complicated things, where you want to run a list through an algorithm that works better on strings, two-dimensional list, or even passing lists in custom block inputs as strings. The OP discusses some of the uses.
I also changed the OP to not showcase the second, more useless block so much now.

JoeyTheChicken wrote:

Hm… We can make the functions on our own, but you drive a hard point. I do think, though, that a dropdown in custom blocks would mean we could make these ourselves, which would be good. I myself was working a while back on something that would have benefitted from this sort of thing. One master loader had to load lots of different lists, so I had custom blocks stacked on top of each other that checked the right conditions individually and had data loaded into them which was essentially a converted list. Under the properly defined conditions, the block would proceed to fill the master list with the converted list, converting it back, and then the loader would load from the master list. Still, custom blocks take care of all of it for me, so once it's done, I don't have to see its face anymore.

Znapi wrote:

JoeyTheChicken wrote:

Hm… We can make the functions on our own, but you drive a hard point. I do think, though, that a dropdown in custom blocks would mean we could make these ourselves, which would be good. I myself was working a while back on something that would have benefitted from this sort of thing. One master loader had to load lots of different lists, so I had custom blocks stacked on top of each other that checked the right conditions individually and had data loaded into them which was essentially a converted list. Under the properly defined conditions, the block would proceed to fill the master list with the converted list, converting it back, and then the loader would load from the master list. Still, custom blocks take care of all of it for me, so once it's done, I don't have to see its face anymore.

Sorry for pushing so hard. I guess this is where the “having everything done for you” comes in. I was making lists in lists/two-dimensional lists. I could go and make scripts to load lists, but I was worried about the speed, and other languages have this functionality(for the mod, all I had to do was list.contents = list2.contents. I don't even know actionscript!). I was also trying to see what I need to clarify/get rid of in my post too, because I have a problem with writing concisely. You seem to understand exactly what I mean now, and everyone is entitled to their own opinion on a topic like this. I'll probably end up making custom blocks to do what the block would do, suggested blocks never seem to be added.