Please allow us to put round blocks (e.g. variables, answer, custom block args, etc.) in the place of variable/list dropdowns

the2000

TheGlassPenguin wrote:
the2000 wrote:
TheGlassPenguin wrote:
I don't support this. Scratch's blocks are designed to prevent the (almost-forgotten) syntax error.
Truthy and falsy variables are a thing, look it up if you don't know what they are
Yes, I do know what they are.

And because of truthy and falsy variables, putting round variables into boolean inputs would not cause a syntax error. There actually is a way to put a round variable into a boolean input in the current version of Scratch. I'll tell you if you're interested.

Edit: Ayy, king of the page!

Last edited by the2000 (Feb. 5, 2021 03:17:48)

Ankit_Anmol

ULTRA SUPPORT!!!!!!! (i too made a topic but…

)

Vienradze

Ankit_Anmol wrote:
ULTRA SUPPORT!!!!!!! (i too made a topic but… )

You mean - a topic about the same thing?

Hearst10

Rendangbike2 wrote:

Support! Why this?:

ask [1 or 2?] and wait
if <(answer) = [1]> then 
broadcast [1 v]
else
broadcast [2 v]
end

Not this?

ask [1 or 2?] and wait
broadcast (answer)

you CAN do the second one

Vienradze wrote:
Hearst10 wrote:
Seapats wrote:
surpport!
please be constructive by saying why you support
I think it's been explained well enough here already.

the ST wants you to be constructive.

TheGlassPenguin wrote:
I don't support this. Scratch's blocks are designed to prevent the (almost-forgotten) syntax error.

this suggestion doesn't let you make syntax errors.

BruiserBear wrote:
Huge support.

Ankit_Anmol wrote:
ULTRA SUPPORT!!!!!!! (i too made a topic but… )

please be constructive by saying why you support

Vienradze

Hearst10 wrote:
Rendangbike2 wrote:
Support! Why this?:
ask [1 or 2?] and wait
if <(answer) = [1]> then 
broadcast [1 v]
else
broadcast [2 v]
end
Not this?
ask [1 or 2?] and wait
broadcast (answer) 
you CAN do the second one
Vienradze wrote:
Hearst10 wrote:
Seapats wrote:
surpport!
please be constructive by saying why you support
I think it's been explained well enough here already.
the ST wants you to be constructive.
TheGlassPenguin wrote:
I don't support this. Scratch's blocks are designed to prevent the (almost-forgotten) syntax error.
this suggestion doesn't let you make syntax errors.
BruiserBear wrote:
Huge support.
Ankit_Anmol wrote:
ULTRA SUPPORT!!!!!!! (i too made a topic but… )
please be constructive by saying why you support

It's useful to write your arguments is you have something new to say. But if you don't, what's so constructive about 10 people writing the same thing?

PGBFLITE6373

the2000 wrote:
TheGlassPenguin wrote:
the2000 wrote:
TheGlassPenguin wrote:
I don't support this. Scratch's blocks are designed to prevent the (almost-forgotten) syntax error.
Truthy and falsy variables are a thing, look it up if you don't know what they are
Yes, I do know what they are.
And because of truthy and falsy variables, putting round variables into boolean inputs would not cause a syntax error. There actually is a way to put a round variable into a boolean input in the current version of Scratch. I'll tell you if you're interested.

Edit: Ayy, king of the page!

tell me

Rendangbike2

gosoccerboy5 wrote:
Rendangbike2 wrote:
Support! Why this?:
snip
I think you can already do that, but you can't do it with the
when I receive [ v]
block.

Lol, sorry but my point still stands

the2000

PGBFLITE6373 wrote:
the2000 wrote:
And because of truthy and falsy variables, putting round variables into boolean inputs would not cause a syntax error. There actually is a way to put a round variable into a boolean input in the current version of Scratch. I'll tell you if you're interested.
tell me

I don't think you were the person I was talking to, but whatever.

if (item (1 v) of [list v] :: list) then

end

For some reason you can do this. Try it out in the Scratch editor if you don't believe me.

PGBFLITE6373

the2000 wrote:
PGBFLITE6373 wrote:
the2000 wrote:
And because of truthy and falsy variables, putting round variables into boolean inputs would not cause a syntax error. There actually is a way to put a round variable into a boolean input in the current version of Scratch. I'll tell you if you're interested.
tell me
I don't think you were the person I was talking to, but whatever.
if (item (1 v) of [list v] :: list) then

end
For some reason you can do this. Try it out in the Scratch editor if you don't believe me.

has i agree with you it wierd, its prob a screw-up by st,

gosoccerboy5

No, it's intentional, it returns if that specific list item exists.

the2000

PGBFLITE6373 wrote:
the2000 wrote:
I don't think you were the person I was talking to, but whatever.
if (item (1 v) of [list v] :: list) then

end
For some reason you can do this. Try it out in the Scratch editor if you don't believe me.
has i agree with you it wierd, its prob a screw-up by st,

It would be difficult to accidentally program that in and then not fix it when people start pointing it out. Anyway, you can see that it returns false with values like 0 and “false”, while returning true with other ones. That's how Scratch could (and I guess if this is any indication, does) use truthy and falsy variables to avoid syntax errors.

PGBFLITE6373

the2000 wrote:
PGBFLITE6373 wrote:
the2000 wrote:
I don't think you were the person I was talking to, but whatever.
if (item (1 v) of [list v] :: list) then

end
For some reason you can do this. Try it out in the Scratch editor if you don't believe me.
has i agree with you it wierd, its prob a screw-up by st,
It would be difficult to accidentally program that in and then not fix it when people start pointing it out. Anyway, you can see that it returns false with values like 0 and “false”, while returning true with other ones. That's how Scratch could (and I guess if this is any indication, does) use truthy and falsy variables to avoid syntax errors.

yeah i agree with you now beacause of this block

set x to <touching color [#706dbc] ?>

is equal to zero

Last edited by PGBFLITE6373 (Feb. 5, 2021 15:46:15)

Maximouse

gosoccerboy5 wrote:
No, it's intentional, it returns if that specific list item exists.

This is definitely not the reason why it exists – you can easily check if an index is out of range anyway (you can't even use this feature to do that because it will also return false if the item at that position equals “false”), and for checking if an item is in a list there is a “contains” block.

the2000 wrote:
It would be difficult to accidentally program that in and then not fix it when people start pointing it out.

They might just consider it not worth fixing. If it was intentional they would also add this feature to normal variables, not just list items, which means that even if it was originally done intentionally, they just forgot to remove it.

Edit: those blocks had the output type set to null (meaning “any”) instead of string since they were added, so it's almost definitely an oversight.

Last edited by Maximouse (Feb. 5, 2021 16:06:28)

Vienradze

PGBFLITE6373 wrote:
the2000 wrote:
PGBFLITE6373 wrote:
the2000 wrote:
I don't think you were the person I was talking to, but whatever.
if (item (1 v) of [list v] :: list) then

end
For some reason you can do this. Try it out in the Scratch editor if you don't believe me.
has i agree with you it wierd, its prob a screw-up by st,
It would be difficult to accidentally program that in and then not fix it when people start pointing it out. Anyway, you can see that it returns false with values like 0 and “false”, while returning true with other ones. That's how Scratch could (and I guess if this is any indication, does) use truthy and falsy variables to avoid syntax errors.
yeah i agree with you now beacause of this block
set x to <touching color [#706dbc] ?>
is equal to zero

What the…

the2000

Maximouse wrote:
the2000 wrote:
It would be difficult to accidentally program that in and then not fix it when people start pointing it out.
They might just consider it not worth fixing. If it was intentional they would also add this feature to normal variables, not just list items, which means that even if it was originally done intentionally, they just forgot to remove it.

I would believe that it was added as an experiment and then they forgot to remove it. I still doubt that it was entirely unintentional, because I'm almost certain that reporters are specifically written to not fit into boolean slots and that this is a hard-coded exception. It is definitely a cool-looking workaround to the current lack of boolean variables, at least.

gosoccerboy5

Vienradze wrote:
What the…

If you place a boolean in a text input it reads it as “true” or “false” but if you put it in a number input it reads it as 1 or 0.

Maximouse

the2000 wrote:
I still doubt that it was entirely unintentional, because I'm almost certain that reporters are specifically written to not fit into boolean slots and that this is a hard-coded exception.

It isn't hardcoded, every reporter needs to have output set to String to not fit into Boolean slots, and these block have it set to null instead.

the2000

Maximouse wrote:
the2000 wrote:
I still doubt that it was entirely unintentional, because I'm almost certain that reporters are specifically written to not fit into boolean slots and that this is a hard-coded exception.
It isn't hardcoded, every reporter needs to have output set to String to not fit into Boolean slots, and these block have it set to null instead.

Oh, well there's the answer. Either way, it proves that Scratch already does use truthy and falsy properties to avoid syntax errors with booleans, and that this would be very easy to implement.

sathvikrias

the2000 wrote:
Maximouse wrote:
the2000 wrote:
I still doubt that it was entirely unintentional, because I'm almost certain that reporters are specifically written to not fit into boolean slots and that this is a hard-coded exception.
It isn't hardcoded, every reporter needs to have output set to String to not fit into Boolean slots, and these block have it set to null instead.
Oh, well there's the answer. Either way, it proves that Scratch already does use truthy and falsy properties to avoid syntax errors with booleans, and that this would be very easy to implement.

https://en.scratch-wiki.info/wiki/Hidden_Features#Code_Editor

the2000

sathvikrias wrote:
the2000 wrote:
Maximouse wrote:
the2000 wrote:
I still doubt that it was entirely unintentional, because I'm almost certain that reporters are specifically written to not fit into boolean slots and that this is a hard-coded exception.
It isn't hardcoded, every reporter needs to have output set to String to not fit into Boolean slots, and these block have it set to null instead.
Oh, well there's the answer. Either way, it proves that Scratch already does use truthy and falsy properties to avoid syntax errors with booleans, and that this would be very easy to implement.
https://en.scratch-wiki.info/wiki/Hidden_Features#Code_Editor

bro i wrote that

Discuss Scratch