For a scratchblocks-interpreting project, I used a

<<(join (letter (1) of (\[scratchblocks\] command)) (join (letter (2) of (\[scratchblocks\] command)) (join (letter (3) of (\[scratchblocks\] command)) (join (letter (4) of (\[scratchblocks\] command)) (letter (5) of (\[scratchblocks\] command)))))) = [Ask []> and <[\] and wait] = (join (letter (length of (\[scratchblocks\] command)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (1)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (2)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (3)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (4)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (5)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (6)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (7)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (8)) of (\[scratchblocks\] command)) (letter ((length of (\[scratchblocks\] command)) - (9)) of (\[scratchblocks\] command)))))))))))>>

block. As you can guess, it's unnecessarily long and difficult to edit or move (I had to zoom out all the way, and when I did that, I couldn't read the scratchblocks because they became pixelated.), but using it, or something like it, was necessary in order to be able to detect the

ask [] and wait

block. It probably generates some lag as well (as all large blocks do). My proposed solution would be to add a

(letters () to () of [world]  ::operators string)

block. It would have a string output, be able to fit in

say []
<[ v] contains [thing] ?>
ask [] and wait

and more.

(letters (k) to (k) of [world]  ::operators string)

would return

(letter (k) of [world])

, and

(letters (c) to (d) of [world]  ::operators string)

would return

(letters (d) to (c) of [world]  ::operators string)

reversed, thus also serving as a workaround for a

(string [] reversed  ::operators)

block. While this is workaroundable, all workarounds for anything longer than four or so letters would either be large, cumbersome to move, and laggy, or use repeat or custom blocks, which would take really long for larger strings and would require either creating a completely otherwise-useless variable, which would cause lag, especially if it's a global variable, or creating a completely otherwise-useless custom block to crowd up the custom blocks space.



For example,

(letters (3) to (5) of [world]  ::operators string)

would return

rld

,

(letters (3) to ((length of [good suggestion]) - (5)) of [good suggestion]  ::operators string)

would return

od sugge

,

(letters (6) to (1) of [Colorado]  ::operators string)

would return

aroloC

, and

(letters (3) to (3) of [Scratch]  ::operators string)

would return

r

.

Support, I dont want to have to remake the block that you used:

<<(join (letter (1) of (\[scratchblocks\] command)) (join (letter (2) of (\[scratchblocks\] command)) (join (letter (3) of (\[scratchblocks\] command)) (join (letter (4) of (\[scratchblocks\] command)) (letter (5) of (\[scratchblocks\] command)))))) = [Ask []> and <[\] and wait] = (join (letter (length of (\[scratchblocks\] command)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (1)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (2)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (3)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (4)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (5)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (6)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (7)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (8)) of (\[scratchblocks\] command)) (letter ((length of (\[scratchblocks\] command)) - (9)) of (\[scratchblocks\] command)))))))))))>>

every time I want to do its action

miniepicness wrote:

Support, I dont want to have to remake the block that you used:

(join (letter (1) of (\[scratchblocks\] command)) (join (letter (2) of (\[scratchblocks\] command)) (join (letter (3) of (\[scratchblocks\] command)) (join (letter (4) of (\[scratchblocks\] command))>> :: operator reporter

-snip-
every time I want to do its action

Same. Support for reasons listed in the OP. I have tried and it is laggy, but for less lag, don't nest the joins.

jromagnoli wrote:

miniepicness wrote:

Support, I dont want to have to remake the block that you used:

(join (letter (1) of (\[scratchblocks\] command)) (join (letter (2) of (\[scratchblocks\] command)) (join (letter (3) of (\[scratchblocks\] command)) (join (letter (4) of (\[scratchblocks\] command))>> :: operator reporter

-snip-
every time I want to do its action

Same. Support for reasons listed in the OP. I have tried and it is laggy, but for less lag, don't nest the joins.

Yes (I trust you.), but it's less convenient to do it that way, and there's still lag.
By the way, thanks for the tip!

So, for anybody who's curious, here is the full workaround, that is the absolute best approximation to the block suggested in the OP, which stores its output in ‘result’:

define letters (a) to (b) of (str) => result
if <<<(a) < [1]> or <(b) < [1]>> or <<(a) > (length of (str))> or <(b) > (length of (str))>>> then
set [result v] to []
stop [this script v]
end
delete (all v) of [chars v]
set [i v] to (a)
if <(a) < (b)> then
repeat (((b) - (a)) + (1))
add (letter (i) of (str)) to [chars v]
change [i v] by (1)
end
else
repeat (((a) - (b)) + (1))
add (letter (i) of (str)) to [chars v]
change [i v] by (-1)
end
end
set [result v] to (chars)

“But that's too long!” I hear you say. Note that this is the absolute complete workaround, that does everything mentioned in the OP (reverse output on backwards indices) and then some (return the same thing as letter (0) of (str) if indices are out of bounds).

For the majority of cases, something much simpler will work, such as:

define letters (a) to (b) of (str) => result
set [i v] to (a)
set [result v] to []
repeat (((b) - (a)) + (1))
set [result v] to (join (result) (letter (i) of (str)))

Note that the only things this block does not support are a) reverse strings, b) bounds checking, and c) strings above the join block limit, which is barely even a problem, as most string manipulation will involve the join block anyways.

Also note that this block will still return a valid value for invalid bounds, simply due to how Scratch bound checks the letter of () block.

If the i variable is bothering you, it gets even better:

define next letter (i) (b) (str)
set [result v] to (join (result) (letter (i) of (str)))
if <(i) < (b)> then
next letter ((i) + (1)) (b) (str)
end

define letters (a) to (b) of (str) => result
set [result v] to []
next letter (a) (b) (str)

And if we had custom reporters, this block would need no variables at all.

To compare, the speed of all three blocks is pretty good for small strings, and the second one should work for almost anything that you would actually need to do in Scratch. It's likely that whatever block the Scratch Team implemented would also be slow on ridiculously large strings, simply because creating substrings, unless they are interned, is by nature an O(n) operation.

My point with this post is that OP's argument that the workaround is laggy / slow is basically moot; although this custom block only works in a single thread, if you are doing multi-threaded string manipulation you are already probably doing something wrong.

I'm honestly not sure where I stand in terms of better string manipulation features in Scratch - certainly they are useful, but figuring out how to implement them myself was honestly one of the best critical thinking exercises I ever received from Scratch. It's important to be able to know how these sorts of operations work on the inside, as it allows you to see how slow they really are - I think people learning to implement them manually is a good experience, and I think that it is not at all bad that Scratch provides it.

I especially think that if we do ever get custom reporters, we should not implement blocks like these - if there were custom reporters (and maybe local variables) than implementing these blocks by hand would have very little negative effect, while it would have a huge educational effect.

Maybe not though. I am using anecdotal evidence here, but I don't think my point is entirely invalid.

Support on behalf of those who want or need it.

I myself feel it would be helpful for savecodes or analyzing answers.

Full support!! I specialize in string manipulation, and having to do

dvargasews wrote:

<<(join (letter (1) of (\[scratchblocks\] command)) (join (letter (2) of (\[scratchblocks\] command)) (join (letter (3) of (\[scratchblocks\] command)) (join (letter (4) of (\[scratchblocks\] command)) (letter (5) of (\[scratchblocks\] command)))))) = [Ask []> and <[\] and wait] = (join (letter (length of (\[scratchblocks\] command)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (1)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (2)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (3)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (4)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (5)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (6)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (7)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (8)) of (\[scratchblocks\] command)) (letter ((length of (\[scratchblocks\] command)) - (9)) of (\[scratchblocks\] command)))))))))))>>

is wasteful of my time. If, in the future, custom reporters are implemented, then I'll accept @TheMonsterOfTheDeep's workaround, if put into such a reporter. Otherwise, this would be perfect. Thank you for suggesting this!

Semi-support, but this is workaroundable by having each character add to a list (add letter 1 to list, add letter 2 to list etc) and then a kind of loop counter variable that does something like this:

set [i v] to [1]
repeat (length of (list :: list))
set [variable v] to (join [(variable)] (item (i) v) of [list v] :: list))
change [i v] by (1)
end

Support, this is extremely useful.

Cub56 wrote:

this is workaroundable by having each character add to a list

set [i v] to [1]
repeat (length of (list :: list))
set [variable v] to (join [(variable)] (item (i) v) of [list v] :: list))
change [i v] by (1)
end

That's not a valid workaround

theonlygusti wrote:

Support, this is extremely useful.

Cub56 wrote:

this is workaroundable by having each character add to a list

set [i v] to [1]
repeat (length of (list :: list))
set [variable v] to (join [(variable)] (item (i) v) of [list v] :: list))
change [i v] by (1)
end

That's not a valid workaround

“not a valid workaround” wut

It still works just fine, and there's no such thing as valid and invalid workarounds.

TheMonsterOfTheDeep wrote:

So, for anybody who's curious, here is the full workaround, that is the absolute best approximation to the block suggested in the OP, which stores its output in ‘result’:

define letters (a) to (b) of (str) => result
if <<<(a) < [1]> or <(b) < [1]>> or <<(a) > (length of (str))> or <(b) > (length of (str))>>> then
set [result v] to []
stop [this script v]
end
delete (all v) of [chars v]
set [i v] to (a)
if <(a) < (b)> then
repeat (((b) - (a)) + (1))
add (letter (i) of (str)) to [chars v]
change [i v] by (1)
end
else
repeat (((a) - (b)) + (1))
add (letter (i) of (str)) to [chars v]
change [i v] by (-1)
end
end
set [result v] to (chars)

“But that's too long!” I hear you say. Note that this is the absolute complete workaround, that does everything mentioned in the OP (reverse output on backwards indices) and then some (return the same thing as letter (0) of (str) if indices are out of bounds).

For the majority of cases, something much simpler will work, such as:

define letters (a) to (b) of (str) => result
set [i v] to (a)
set [result v] to []
repeat (((b) - (a)) + (1))
set [result v] to (join (result) (letter (i) of (str)))

Note that the only things this block does not support are a) reverse strings, b) bounds checking, and c) strings above the join block limit, which is barely even a problem, as most string manipulation will involve the join block anyways.

Also note that this block will still return a valid value for invalid bounds, simply due to how Scratch bound checks the letter of () block.

If the i variable is bothering you, it gets even better:

define next letter (i) (b) (str)
set [result v] to (join (result) (letter (i) of (str)))
if <(i) < (b)> then
next letter ((i) + (1)) (b) (str)
end

define letters (a) to (b) of (str) => result
set [result v] to []
next letter (a) (b) (str)

And if we had custom reporters, this block would need no variables at all.

To compare, the speed of all three blocks is pretty good for small strings, and the second one should work for almost anything that you would actually need to do in Scratch. It's likely that whatever block the Scratch Team implemented would also be slow on ridiculously large strings, simply because creating substrings, unless they are interned, is by nature an O(n) operation.

My point with this post is that OP's argument that the workaround is laggy / slow is basically moot; although this custom block only works in a single thread, if you are doing multi-threaded string manipulation you are already probably doing something wrong.

I'm honestly not sure where I stand in terms of better string manipulation features in Scratch - certainly they are useful, but figuring out how to implement them myself was honestly one of the best critical thinking exercises I ever received from Scratch. It's important to be able to know how these sorts of operations work on the inside, as it allows you to see how slow they really are - I think people learning to implement them manually is a good experience, and I think that it is not at all bad that Scratch provides it.

I especially think that if we do ever get custom reporters, we should not implement blocks like these - if there were custom reporters (and maybe local variables) than implementing these blocks by hand would have very little negative effect, while it would have a huge educational effect.

Maybe not though. I am using anecdotal evidence here, but I don't think my point is entirely invalid.

I'ma steal this if you don't mind

100% full support. I've been in this situation once and it really is helpful to have this block at hand!

(letter (1) to (4) of [thing] :: operators)

Climax999

The4thPixel wrote:

theonlygusti wrote:

Cub56 wrote:

this is workaroundable by having each character add to a list

set [i v] to [1]
repeat (length of (list :: list))
set [variable v] to (join [(variable)] (item (i) v) of [list v] :: list))
change [i v] by (1)
end

That's not a valid workaround

“not a valid workaround” wut

It still works just fine, and there's no such thing as valid and invalid workarounds.

There is. A workaround is often labelled “invalid” when it doesn't replicate what the OP asks for.

The OP specifically states that it should be possible to substring from a higher index to a lower one, thus resulting in a reversed version of the input.

The above workaround cannot do this, and is thus invalid.

theonlygusti wrote:

The4thPixel wrote:

theonlygusti wrote:

Cub56 wrote:

this is workaroundable by having each character add to a list

set [i v] to [1]
repeat (length of (list :: list))
set [variable v] to (join [(variable)] (item (i) v) of [list v] :: list))
change [i v] by (1)
end

That's not a valid workaround

“not a valid workaround” wut

It still works just fine, and there's no such thing as valid and invalid workarounds.

There is. A workaround is often labelled “invalid” when it doesn't replicate what the OP asks for.

The OP specifically states that it should be possible to substring from a higher index to a lower one, thus resulting in a reversed version of the input.

The above workaround cannot do this, and is thus invalid.

define extract characters (a) to (b) from [fullstring]
if <(a) > (b)> then
extract characters (b) to (a) from (fullstring)
end

would work, but it would be even laggier.

dvargasews wrote:

define extract characters (a) to (b) from [fullstring]
if <(a) > (b)> then
extract characters (b) to (a) from (fullstring)
end

would work, but it would be even laggier.

Umm you'll need to have a result var somewhere.

Sigton

I am working on a scratch extension that this programmed as a feature

Just install the extension then it will add these to your more blocks page on scratch

NitroBlock is available here

Unfortunately, it will require the other users to have the extension also.

nitroblock? ::extension boolean //Use this to prevent people from using the project without getting the extension.

theonlygusti wrote:

Support, this is extremely useful.

Cub56 wrote:

this is workaroundable by having each character add to a list

set [i v] to [1]
repeat (length of (list :: list))
set [variable v] to (join [(variable)] (item (i) v) of [list v] :: list))
change [i v] by (1)
end

That's not a valid workaround

This isn't a direct workaround for that specific block, it is just a way of extracting characters from a string one by one. Then the output can be stored in a variable

Cub56 wrote:

this is workaroundable

A few moments later…

Cub56 wrote:

This isn't a direct workaround

NitroCipher wrote:

I am working on a scratch extension that this programmed as a feature

Just install the extension then it will add these to your more blocks page on scratch

NitroBlock is available here

Unfortunately, it will require the other users to have the extension also.

nitroblock? ::extension boolean //Use this to prevent people from using the project without getting the extension.

Are there limits on the use of extensions in Scratch?

dvargasews wrote:

NitroCipher wrote:

I am working on a scratch extension that this programmed as a feature

Just install the extension then it will add these to your more blocks page on scratch

NitroBlock is available here

Unfortunately, it will require the other users to have the extension also.

nitroblock? ::extension boolean //Use this to prevent people from using the project without getting the extension.

Are there limits on the use of extensions in Scratch?

The ST doesn't like people sharing projects on the Scratch site that require extensions, but I can't remember what they do with them. It might get marked as NFE.