Discuss Scratch
- Discussion Forums
- » Suggestions
- » Unevaluated procedure parameters
- scimonster
-
1000+ posts
Unevaluated procedure parameters
For every block in a program, Scratch first evaluates (figures out) the arguments (inserts) to the block, and then the block itself. Same as any language, really. This applies to built-in and custom blocks equally.
The only exception that i know of is the repeat until <> block. It cannot evaluate the Boolean immediately, because it must keep doing so.
Last week, i saw this topic, saying that they were having a problem with their custom block. It was because an evaluated value was being passed.
So, now to the suggestion itself:
Don't evaluate parameters to custom blocks. They can be asked for at runtime.
This script won't work. Why not? It will either never run, or never stop. That is because <cond> will be either true or false, depending on what it was at the start.
With this suggestion, the script there would work. Why is that? <cond> would not always be what it started as. It would actually report the current state of the expression passed in.
I've been suggesting this for Boolean values, but why limit it like that? Why not also for reporters?
As it is, (val) is a ‘snapshot’ (thanks for the term, DOML) of the y position at the time of the custom block's beginning. With this suggestion, it would actually be a reference to the outer value. In other words, it would behave like it was actually the (y position) block, not (val).
What do people think of this idea? It's unlikely to break anything, and people seem to expect this functionality.
For someone who actually does want a ‘snapshot’, there's a pretty easy solution:
The only exception that i know of is the repeat until <> block. It cannot evaluate the Boolean immediately, because it must keep doing so.
Last week, i saw this topic, saying that they were having a problem with their custom block. It was because an evaluated value was being passed.
So, now to the suggestion itself:
Don't evaluate parameters to custom blocks. They can be asked for at runtime.
This script won't work. Why not? It will either never run, or never stop. That is because <cond> will be either true or false, depending on what it was at the start.
With this suggestion, the script there would work. Why is that? <cond> would not always be what it started as. It would actually report the current state of the expression passed in.
I've been suggesting this for Boolean values, but why limit it like that? Why not also for reporters?
As it is, (val) is a ‘snapshot’ (thanks for the term, DOML) of the y position at the time of the custom block's beginning. With this suggestion, it would actually be a reference to the outer value. In other words, it would behave like it was actually the (y position) block, not (val).
What do people think of this idea? It's unlikely to break anything, and people seem to expect this functionality.
For someone who actually does want a ‘snapshot’, there's a pretty easy solution:
- PH-zero
-
100+ posts
Unevaluated procedure parameters
hmm… i actually would expect that as a “snapshot”.
custom blocks are different from messages, not only because they can't be broadcasted
or they can have parameters.
They also have the option “run without screen refresh”.
For example:
One idea of custom blocks (at least in my opinion)
is that they should give the illusion of being hard-coded into scratch as well.
This is why “run without screen refresh” is there. (at least i have no other explanation for that…)
custom blocks are different from messages, not only because they can't be broadcasted
or they can have parameters.
They also have the option “run without screen refresh”.
For example:
There is no
This block is hard-coded into scratch.
One idea of custom blocks (at least in my opinion)
is that they should give the illusion of being hard-coded into scratch as well.
This is why “run without screen refresh” is there. (at least i have no other explanation for that…)
- scimonster
-
1000+ posts
Unevaluated procedure parameters
Um, where did i mention messages/broadcasts? hmm… i actually would expect that as a “snapshot”.
custom blocks are different from messages, not only because they can't be broadcasted
or they can have parameters.
They also have the option “run without screen refresh”.
- AonymousProfessor
-
100+ posts
Unevaluated procedure parameters
Duplicate. (Well, it's the same suggestion with a different name)
- scimonster
-
1000+ posts
Unevaluated procedure parameters
Duplicate. (Well, it's the same suggestion with a different name)Hmm, i had searched, but it didn't come up.

- Discussion Forums
- » Suggestions
-
» Unevaluated procedure parameters