make the ask bock a reporter

sathvikrias

returning something is an action.

the2000 wrote:
If you actually read his post all the way through you would see that he clearly does on some level.

I know.

the2000

sathvikrias wrote:
returning something is an action

Returning something, on its own, is not an action. A random variable sitting in the workspace attached to nothing won't do anything when activated. Currently in order for variables to have any use on the end project they need to be manipulated by another block.

han614698

-snip-

Edit:

Maximouse wrote:
han614698 wrote:
I don't think so. . .
The “translate” block in the Translate extension is also a reporter that performs an action (sends the text to Google Translate). This block would be similar, but instead of asking Google Translate it would ask the user.

I don't really know if that counts as “performing an action” since it doesn't effect the project visibly in any way. It's not performing an action as much as it is fetching the value externally; it's just outsourcing the way that it determines the value to report and not much else
ah, yes.. . .the translate block. thats basically what i was trying to say.

SpinningCube

I think the people in here talking about “actions” are describing the programming term, “side effects” which modify values outside their local environment.

han614698

BUMPPITY BUMP BUMP

rdococ

No support - there are good reasons why 'ask [] and wait' and ‘answer’ are separate blocks in the first place.

The ‘ask’ block does something rather than just calculating a value, so it makes sense for it to be a command block. Most programming languages will happily allow procedures to perform actions (“side-effects”) and return values, but Scratch makes a clear, intuitive distinction between commands and reporters, and I think it's a good idea to keep that distinction.
The evaluation order is unclear. Scratch almost surely just calculates a block's inputs from left to right, but there's no obvious indication that it does that - reporters are simply just not designed to represent sequential actions where order matters.
Only one ‘ask’ can happen at a time anyway, so you're not losing anything by having to use a global ‘answer’ “variable” rather than being able to store it directly into a for-this-sprite-only variable.
If you want to check if the answer equals one of several possible choices, you don't have to create a new variable to do so - you can just use the existing ‘answer’ reporter, which is hugely convenient. This is even more helpful for the new Scratchers who haven't figured out variables quite yet.

gosoccerboy5

bump

mybearworld

…How did you find this again? Well, I still think that this is way easier and way more efficient, I really needed this when making projects.

Prime689

a wild dupe appeared

mybearworld

Last edited by mybearworld (June 26, 2021 20:08:18)

mybearworld

Support. My points are that this would make code more efficient and make it work a bit more like other programming languages.

I made a duplicate, there are some good points there.

necropost!!!!!!1111!!11!!1

-Kryptonite-

Support, pretty useful!

samq64

Support. It makes no sense why it's a stack block to begin with, I never use the answer reporter unless it's to store the answer in a variable anyway.

Last edited by samq64 (June 25, 2021 23:24:25)

Thingied

Little support. Won't make much sense to beginners but would make some scripts shorter.

DJUmbreon2

SuperJumpCube wrote:
I personally support the addition of this block, but then add it to some sort of ‘Advanced Blocks’ extension on scratch 3.0.
Doing so takes away the problem of kids not understanding what each block does when coding, but it does give the problem of kids not understanding your code when looking inside the project(Not as if I understood anything anyways). Once a solution has been brought to this problem, I'd love to see such a block in scratch 3.0

And yet it isn’t here

DJUmbreon2

space_elephant wrote:
because there is no reason to make it be a stack block that sets a reporter
it should look like
(ask [thing] and wait)
in older projects with the other ask,
ask[thing]and wait
say(answer)for(2)secs
think(answer)for(2)secs
would be replaced with
set[answer v]to(ask[thing]and wait)
say(answer::variables)for(2)secs
think(answer::variables)for(2)secs

No support, too much ambiguity

k7e

DJUmbreon2 wrote:
space_elephant wrote:
because there is no reason to make it be a stack block that sets a reporter
it should look like
(ask [thing] and wait)
in older projects with the other ask,
ask[thing]and wait
say(answer)for(2)secs
think(answer)for(2)secs
would be replaced with
set[answer v]to(ask[thing]and wait)
say(answer::variables)for(2)secs
think(answer::variables)for(2)secs
No support, too much ambiguity

What ambiguity?

Greg8128

Scratch operates under the assumption that all reporter blocks have no side effects. (That is, it doesn't matter in what order two reporter blocks get called, or whether a reporter block gets called at all if its result doesn't matter).

An "ask and wait“ reporter would violate this principle. Suddenly, Scratch would have to standardize the order in which reporters are calculated, and whether the ”or“ and ”and" boolean blocks must always evaluate the right side. This would make it much harder to ensure backwards compatibility.

Reev0102

Support. This feature is already there in other programming languages, and it would help to keep the code short:

when green flag clicked
set [foo v] to (ask [What's your name?] :: sensing)

instead of

when green flag clicked
ask [What's your name?] and wait
set [foo v] to (answer)

I don't see why this shouldn't be added.

PkmnQ

A better way to do this would be

set [foo v] to ask [What's your name?] and wait :: sensing

Discuss Scratch