Now...I wasn't here to witness this feature, but I'm curious...
Does anyone remember the blocks that existed before the gray rings? (Sorry for the bad reporter picture)
Ahem...
Sure, I do... was there a question?
Why did you remove them?
Well, it wasn't so much removal as reshaping visually.
Those blocks were wide and tall, making even pretty simple scripts look imposing, and complicated scripts unbearable. Even more important, we learned that these ideas are easier to teach and learn if blocks that expect blocks or scripts as input said so, and the gray ring in blocks such as MAP is way more manageable than putting a THE BLOCK block in that input slot in the palette.
We also decided, after a lot of discussion, that the value reported by a ring should itself be visually equal to that ring. This isn't quite right; the gray ring is LAMBDA, an input syntax notation that creates a procedure. The procedure itself doesn't have a visual representation in Scheme; it displays as something like #procedure[...] where the ... is something opaque such as the procedure's memory address in hex. Our notation suggests that a procedure is equivalent to its text (its parameters and body), whereas really there's a third invisible component, the environment in which it was defined. But if you're a beginner it's quite a while until that becomes relevant.
It took us three iterations to get gray rings exactly right, but I think we got there in the end. It's powerful, compact, and learnable. In a context like higher order functions, in which we mainly teach this, you can think of the ring as a syntax meaning "don't evaluate this yet" without having to think about how that don't-evaluate is implemented through first class procedures.
The other syntax to make a procedure is the C-shaped input slot, which should really be lined with a ring. But since we teach about functions before looking behind a C-slot, we can let students roll with their initial understanding of C-slots from Scratch for a while.
You can implement THE BLOCK by giving it an input of type "Unevaluated (any)" and just reporting the input.
they were deleted because ringed scripts exist now
great TLDR!
thx
What was the second iteration (or first)?
It should be pretty easy to make this still
What did the arrow on “the script” block do
Also
Ring text
Side note, is there a way to report a block with inputs? Like I wanna report a “move () steps” block with its inputs as “round (10.4)” and I want the block to report the block as “move (round (10.4)) steps”
Just insert the block into the input, place the whole reporter into a gray ring, and it should report that...right?
EDIT: It works
I'm still a bit confused by what you're saying. The call block wouldn't work in this instance, as it requires a reporter and not a command. Additionally, the round reporter in the gray ring would not provide any function with the move steps command; the input is for numbers.
Just to doublecheck, I replicated the script you showed, but, as I expected, it didn't work. I also tried replacing the call blocks with run blocks, but it still didn't work. The inputs for call are supposed to be reporters, and the gray ring around the round block wouldn't work correctly in that context.
See this
Ignoring the (important) distinction between CALL and RUN, there's no need for two invocations. The inner one (which should be RUN) does all the work of moving.
(Footnote: in order for it to use the input expression you provided, you have to erase the 10 in the MOVE block, so it says MOVE ( ) STEPS. Otherwise there's no empty slot into which RUN can substitute your input.)
If you really want to build an instruction to save for later, such as a MOVE with a ROUND in its input slot, you are doing metaprogramming, and you have to build up a list structure which, when converted to code, will be the code you want. To figure out how to do that, work backwards from the result you want:
And then write code to construct that list in the result bubble.
Ringed text...
The ULTIMATE ultimate! The one ring to rule the ring to rule them all!
Yes...I did watch the TEDx video.
My fork of Super-Snap! revived that blocks, just are these of above:
Originally, in Snap! 4.0 beta, remains the selectors of that blocks, but they are never used.
For "the script %parms %c" its selector is reportScript.
For "the %f block %parms" its selector is reify.
That's why reifyScript, reifyReporter and reifyPredicate are similar in names to them.
In Super-Snap! I modified the original MultiArgMorph.prototype.fixLayout to this:
MultiArgMorph.prototype.fixLayout = function () { var labels, shadowColor, shadowOffset; if (this.slotSpec === '%t') { this.isStatic = true; // in this case I cannot be exchanged } if (this.parent) { labels = this.allLabels(); this.color = this.parent.color; this.arrows().color = this.color; if (labels.length) { shadowColor = this.shadowColor || this.parent.color.darker(this.labelContrast); labels.forEach(label => { shadowOffset = this.shadowOffset || (label ? label.shadowOffset : null); if (!label.shadowColor.eq(shadowColor)) { label.shadowColor = shadowColor; label.shadowOffset = shadowOffset; label.fixLayout(); label.rerender(); } }); } } this.fixArrowsLayout(); MultiArgMorph.uber.fixLayout.call(this); if (this.parent instanceof BlockMorph) { if (this.arrows().children[0].isVisible) { if (this.parent.selector === 'reportScript') { if (this.parent.children[1] instanceof StringMorph) { this.parent.children[1].text = localize('script.'); this.parent.children[1].fixLayout(); };} else if (this.parent.selector === 'reify') { if (this.parent.children[2] instanceof StringMorph) { this.parent.children[2].text = localize('block.'); this.parent.children[2].fixLayout();};};} else { if (this.parent.selector === 'reportScript') { if (this.parent.children[1] instanceof StringMorph) { this.parent.children[1].text = localize('script'); this.parent.children[1].fixLayout(); };} else if (this.parent.selector === 'reify') { if (this.parent.children[2] instanceof StringMorph) { this.parent.children[2].text = localize('block'); this.parent.children[2].fixLayout(); };};};}; if (this.parent instanceof Morph) { this.parent.fixLayout();}; };
This is the example:
Did you know that this feature is on BYOB (Snap! ancestor) like above too? 
@blockpointstudios Also thank you for reviving the question too!!! 
The thing is, those blocks are useless now because you can ring scripts, which make them act the exact same as those blocks. Cool though, not being mean!
Ok, but thank you too!!! 
ur welcom