(()@>) ({}@>) (<>@>) :: #FFFFFF
kindof confusing
first, how are they grey, in operator tab
second, how are they in a horizontal line
third, how is there empty space inside of them and why cant i do that with my own blocks
The answer to all three of your questions is that these are special blocks that get special treatment.
Custom blocks cannot mix between categories, but primitive blocks (the main snap blocks) can.
Solution:
({}@> :: operators)
[sb] ({}@> :: operators) [/sb]
(lol)
(This is actually correct, though.)
but why is this so problematic?
The question you should first be asking is "what does a gray ring mean?"
To answer that, here's a 1000-word-worth picture:
In the first picture, 2+3 is computed, by invoking the + function. The value is 5. In the second picture, the value of the ringed expression is the expression itself.
What good is an expression as a value? You can CALL it:
This isn't very interesting when the expression has a constant value, but it's more interesting if the expression is a function with an empty input slot:
That last example shows the use of a higher order function, a function that takes another function as an input.
Now, please read Chapter VI of the manual for the answers to all your questions.
If it is grey and in the Other category, the rings would be buried a bit too deep to find.
So space is not wasted. The rings are small enough to be arranged in three columns. Would you consider rings stacked like that to be a waste of space considering that they could fill in the right side?
({} @>)
(() @>)
(<> @>)
The holes are to make it look welcoming to fit blocks inside. It's a special type of block designed to do what it is meant to do.
I'm sure they are referring to blocks in Snap! rather than snapblocks which has freedom in this.
I know, it was just a little joke.
It would be especially wasteful since people hardly ever have to use the rings from the palette. In the most common case, namely using a function as input to a HOF, the ring is already provided in the input slot; in more advanced situations, power users use the "ringify" option in an expression's context (right-click) menu.
definitely agree, I don't remember the last time when I dragged one from the palette.
how do i put the empty space in my own things
because that isnt empty hello {}
and i dont mean the ring input hello ({} @>)
i want the type of input that is the empty space in ({} @>)
like how do i even do it in snapblocks
Short answer: you don't.
We don't think of it the way you're thinking, as the ring being a block with an input. It's more like, the ring is a modifier wrapped around the expression or the script.
In more technical, less metaphoric terms, Snap!, like most programming languages, uses applicative order evaluation, which means that the inputs to a block are computed before the block itself is invoked. That is, when you say 
, the + block knows only that its inputs are 3 and 20; it doesn't know that you did a multiplication to compute the 20.
But rings are the big exception to that. The whole point of a ring is that what's inside it isn't computed; the ringed expression itself is the input to something else. If you think of the ring as a block, you'd expect its input to be evaluated before the ring has a chance to prevent evaluation.
A C-shaped input slot is also exceptional; it implicitly rings the script inside it. (Historically, C-shaped blocks in Scratch came before Snap! rings, but they still had the meaning of a ring, namely deferring the evaluation of the script in the slot. Scratch doesn't have a notation for deferring the evaluation of an expression, just for scripts.)
why?
A different answer to bh's, but: The way I read this: the two rings here are equivalent. The ring's 'empty slot' is transparent. So, it's grey on grey blocks, blue for blue blocks, etc. In part this distinguishes the ring input in a block more clear from any ordinary input where a function would be evaluated.
The answer is, you can only use it on the first input of ring shape blocks. The reason is because they're specialized inputs on a special block shape.
Here's a workaround using white blocks instead (won't work on forum dark mode):
[snapblocks]
hello {\ ::cap #ffffff}
hello (\ \ \ \ :: #ffffff)
hello <\ \ \ :: #ffffff>
[/snapblocks]
hello {\ ::cap #ffffff}
hello (\ \ \ \ :: #ffffff)
hello <\ \ \ :: #ffffff>
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.