play around with the new feature Redirecting to Snap! like this topic 
I can't figure out how it works, but here is my suggested implementation of hat blocks:
The event hat block would be used to define the existing hat blocks. Here is an example of a custom hat block:
I'm thinking run "this continuation" would run the script beneath the block.
report <cond>
is
when <cond>
how about (this [continuation V]) of (this [caller V])
Thanks for the explanation! This is interesting (however, I am not sure that I will ever use it).
No point if the report block reporting a condition already starts the script beneath it.
I mean, it would be nice to be able to use a parameter as part of the define hat outside the block that just reported the contents of the script below the hat.
This experimental feature (no promises of it being released) is just syntactic sugar for the existing generic WHEN hat block. Like generic WHEN, custom hat blocks don't fire after clicking the stop sign until some other script runs.
yeah I know, but if this is released, there would probably be other things that would also be added for metaprogramming and stuff like maybe ringifying, so possibly more than
. but we're just playing around
If we made rings for custom hat blocks, I'm sure we would also allow primitive hat blocks in the ring, including a generic WHEN with its predicate input slot filled. So, I stand by "syntactic sugar."
Well, not quite, actually, because custom hat blocks can take inputs. If we adopt this feature for real, we should perhaps also add a right arrowhead to the generic WHEN block to allow for inputs.
yeah thats what I meant.
why? cant you call (()@addInput) with inputs [] [] @delInput @addInput
Can't the inputs just be in a custom predicate in the input slot?
That's ordinarily how the caller passes inputs to a block, but you can't CALL a hat block, so it'd have to be BROADCAST ... WITH DATA ... or some such thing. I'm thinking about how, for example, to do something like the way WHEN KEY ... PRESSED gets an upvar KEY if the menu input is set to "any key."
Maybe, but we want input slots to be visible in the WHEN block, so, what, we add as many input slots to the WHEN block as the predicate has inputs? I suppose.
I'm not entirely sure I get what you're talking about, since the custom hat blocks are just syntactic sugar for the boolean slot in the generic when block (the whole definition would go in the boolean slot). For allowing inputs, it's as if the whole definition were in a custom predicate. So something like this
{when ((input 1)) is ((input 2)) :: operators hat} :: define+
report <(input 1) = (input 2)>
when [5] is [5] :: hatWould become
<((input 1)) is ((input 2)) :: operators> :: define+ report <(input 1) = (input 2)> when <[5] is [5]>
or
when (call (<(input 1) = (input 2)> input names: ((input 1)) ((input 2)) @delInput @addInput) with inputs [5] [5] @delInput @verticalEllipsis @addInput)
There wouldn't really be a need for
when (<(input 1) = (input 2)> input names: ((input 1)) ((input 2)) @delInput @verticalEllipsis @addInput) with inputs [5] [5] @delInput @verticalEllipsis @addInput :: control hat
I guess. It didn't occur to me to use WHEN (CALL ...). :~)
@ego-lay_atman-bay is right, there is absolutely no need for a "with inputs" expansion in the generic WHEN hat block, because you can simply make a custom predicate. You can even have the custom predicate expose upvars, and use these in the script attached to the WHEN hat block, if you like.
The point of the new custom hat blocks is abstraction, to hide away more complex stuff inside the hat definition so what you actually use them for becomes more expressive and straightforward to understand / communicate with others. One of my guiding examples and use cases is that in years of workshops with children they'll often make a football / soccer / tennis game, and the two common bugs they always encounter is that they believe that the statement
if <(ball) touching (net)>
change (score) by (1)
expresses a general rule instead of a fleeting, momentary and singular test.
So when some more experienced friend tells them to wrap that conditional inside a forever loop and attach a when (green flag) clicked hat to it they encounter the second bug, which is that now the score variable always keeps counting up in irregular intervals, instead of just a single step whenever the ball hits the goal net. That second bug is much harder to fix, and few friends in school have the experience to point out that now you need to add something like
wait until <not <(ball) touching (net)>>
to stop the goals from incrementing forever. Even many (of not most) teachers have problems with this concept, because they are not used to thinking in parallel terms, because they have been trained on classical, single-threaded "game-loop" languages, especially if they have a college degree in computer science.
So, while I believe that finding out about these intricacies can be great and helpful I also think that being able to abstract these away into a hat block that expresses a rule can be a very liberating and powerful method to reflect about multi-threaded systems.
I am, however, not at all sure whether I want to add metaprogramming capabilities for hat blocks. So please, don't ask for them.
I just had a great insight that I should have had long ago. You don't believe in closure! Not in the lambda sense, but in the group axioms sense; if operation ⊕ forms a group over set S, then ∀x,y ∈ S, x⊕y ∈ S. (The lambda version gets its name from this math meaning.) How this applies to features is that I automatically think that if x = metaprogramming and y = custom hat blocks, then of course x⊕y (metaprogramming of custom hat blocks) has to be a feature, but there's nothing "of course" about it at all. I think this must be related to our differing tastes with respect to Eisenberg's Law. :~)
(I have the probably entirely wrong view that if features are implemented correctly then you should get closure in this sense without extra effort.)
When your not busy ,could you give a simple example of using the new hat to abstract the ball touching net problem as I'm not seeing how to do this
I don't understand how closures have anything to do with your (I think faulty) idea of "Eisenberg's law". And allegations about "correctness", especially wrt implementation, gets my blood boiling. The question to me always is this: "How does this feature help me express something?". Metaprogramming is problematic in itself, because - as we see time and again in this forum, it mostly doesn't help, but confuse people. Folks in this forum mostly ABUSE metaprogramming for all the wrong reasons, basically because they can't program right, so they think that if they only knew about JavaScript or "advanced" stuff that you and I get excited about (closures and metaprogramming) they could do more impressive projects. That's why we have endless discussions here about patently stupid demands, e.g. to reference variables by their names instead of using the getter reporters. Most of the metaprogramming stuff is just incompetence to think straight.
here's a slightly different example along the same idea, recreating Scratch's "when backdrop switches to ..." hat block:
You only want to fire the event once, whenever the background changes to the specified one.
Are saying the teachers can write the complicated code, to only react once to an event, and then just include the block in a starter project?
exactly, yes. I'll add one or two libraries with these events - and perhaps also a generalized "when" - "once" - "when ... changed" version that will cover these patterns:
maybe it's even better to abstract these patterns into predicate blocks that can be used inside custom hat blocks. Then it'll be even easier to express these kinds of rules.