When <> hat block

[sathvikrias]

I saw in the FAQ

@bh

Hat blocks: We have an equivalent feature, the "generic WHEN block":

You can put any Boolean expression in the hexagonal input slot.

it is NOT an equivalent feature; the when <> hat block has that special rule about the stop sign being a square, and so I suggest you actually add custom hat blocks. or, make it so instead of the stop sign stopping the when <> hat block, the pause sign does.

[snapenilk]

Well, if you click the stop sign and when <> is still running, is the program actually stopped? The previously running scripts are stopped, but something would still be.

What would you want a custom hat to do that when <> doesn't support?

Question for devs: should the stop button stop all hat blocks?

[sathvikrias]

@snapenilk

What would you want a custom hat to do that when <> doesn't support?

have you–

@sathvikrias

it is NOT an equivalent feature; the when <> hat block has that special rule about the stop sign being a square

[snapenilk]

So what you want is for when <> to not stop when the user clicks the stop button?

[sathvikrias]

either

@sathvikrias

actually add custom hat blocks.

@sathvikrias

or, make it so instead of the stop sign stopping the when <> hat block, the pause sign does.

[snapenilk]

I thought the pause sign would pause the when <> blocks, but it doesn't. That can be used to create a custom when paused hat (create a predicate that detects if the program is paused and put it in when <>).

The stop sign stopping when <> prevents when <malicious code> or when <true> {malicious code} from running indefinitely. Nothing should be running when the user or developer wants to stop a program, which is done with the stop sign.

[sathvikrias]

that doesn't make sense.

[snapenilk]

Could you tell me which part you don't understand?

[sathvikrias]

@snapenilk

I thought the pause sign would pause the when <> blocks, but it doesn't. That can be used to create a custom when paused hat (create a predicate that detects if the program is paused and put it in when <>).

????

@snapenilk

The stop sign stopping when <> prevents when <malicious code> or when <true> {malicious code} from running indefinitely. Nothing should be running when the user or developer wants to stop a program, which is done with the stop sign.

then why don't the other hat blocks have that rule?

[snapenilk]

The part of the answer that I do know is that they are guaranteed safe because they don't run anything that a [potentially malicious] Snapper puts into them.

[sathvikrias]

but it can't be used to make a when paused hat, since the pause would be stopping all hat blocks (including custom hat blocks if the developers agree to add them).

[snapenilk]

@snapenilk

I thought the pause sign would pause the when <> blocks, but it doesn't.

It still works (for now, at least).

[bh]

@snapenilk

Question for devs: should the stop button stop all hat blocks?

In a perfect world, we wouldn't have to worry about misbehaving scripts (whether malicious or just buggy). Then the stop button would just mean "stop everything right now," without being stateful.

The other hat blocks only fire when the user does something, with the keyboard or with the mouse. (When I receive looks like an exception, but if scripts are stopped, they can't be broadcasting.)

If we ever reimplement the old BYOB mesh network or equivalent, then I guess we'd have to add cross-network broadcasts to the category of hat blocks disabled after stop.

[bh]

@sathvikrias

but it can't be used to make a when paused hat

Do you have a practical application for this? I'm afraid we started this quest to override the UI by adding when I am stopped, but we did that for a specific reason: to allow robot software to turn off their motors when the user stops the program. I don't know of a corresponding need for when-paused. If there is one, then we'd think about supporting that.

---

@jens: Okay, you win, I hereby acknowledge that there are UI features that don't have to be possible in user code. (I still think there aren't many, though.)

[sathvikrias]

I feel like this is getting off-topic. I said

@sathvikrias

it is NOT an equivalent feature; the when <> hat block has that special rule about the stop sign being a square, and so I suggest you actually add custom hat blocks.

and I don't see what's wrong with that.

[bh]

@sathvikrias

and I don't see what's wrong with that.

I thought I'd explained this, but maybe I'm wrong about that.

Even if we built a fancy UI for custom hat blocks, they'd still have the same safeguards that the generic WHEN block has. Snap! isn't C, a language that was designed to allow system programmers to do anything, with no protection against mistakes. C's designers weren't trying to make an educational language for beginners; they were aiming at the very most experienced programmers, who until then had been forced to code in machine language because no higher-level languages before C were flexible enough for programming an operating system.

That's not our mission. We want to make it easier for beginners to engage with powerful ideas in computer science, things like higher order functions. Part of "make it easier" is that users shouldn't be screwed by bugs in their own code or by malicious features of someone else's code.

Obviously we could take that too far. We let you put input values of any type into any input slot, regardless of the type that the slot expects. That can be a way to shoot yourself in the foot, but it can't make it impossible for you to stop your program. There's room for disagreement about exactly where to draw the line, but we think unstoppable programs are clearly on the wrong side of it.

If there's a specific thing you want to do, for a real reason, that you can't do with generic WHEN, we'd consider adding support for that specific thing.