Why does input unringify?

Help with Snap! Snap! Editor
1

In any new Snap! script

  • create a new variable (global or local)
  • drag an 'ask' block onto the scripting area
  • drag the variable into the ringified input
  • ringify goes away -- it needs to be right-click...ringify to get it back

Why does it do that? I would think since the ask block shows the input ringified, it would stay that way when you try to use it

Reason I'm asking, I'm working U5L2 Pandemic Simulation project with my class, and when I tried to use

for nbor in (my neighbors) {
say (ask nbor for infected)
}

it unringified when I dragged in the sprite variable 'infected', so it didn't work (until I had to manually re-ringify it)

2

It is because variables can store blocks inside a ring...
If you want to use the variable ringified, just right click and ringify it!

3

I don't know what you mean by 'variables can store blocks inside a ring'

I do want to use the variable ringified, and since the ask block shows as ringified in the palette, it makes more sense to me that it should be/stay ringified by default. There's always the option to unringify if necessary.

4

I mean, variables put the ring out because they are not intended to be ringified by default.

What do you mean with this?

5

WHen you look at all the blocks available in the palettes on the left pane, and the ask block is one of the blocks in the Control/yellow palette, the picture of the ask block that you can drag onto your script to use, has its empty input showing a grey ring. And then when you do drag it on, the empty input still has a grey ring.

So you're saying a more natural way to do what I'm doing is to implement a 'getter' custom block that will report the variable, and I put that block into the say and it will stay ringified?

6

Yes, I know...

Then I put the variable, it unrigifies the input

7

That's exactly the unexpected behavior I don't like

9

You're the second person in the recent past to call this to our attention. The "this" is that the default ring behavior isn't what people want from ASK.

But ASK is a special case. To understand the behavior of rings and variables, think about any other block with a ringed input, e.g., CALL or MAP. In those non-ASK cases, what does the user mean when they drag a variable into the ring slot? Almost always, it means that the value of the variable is an expression or a script, and the user wants to run that expression or script. For example, here's how you can write MAP in Snap!:

untitled script pic
untitled script pic1304×470 93.3 KB

Look how FUNCTION is used both in the CALL block and in the recursive call to MAP. The value of FUNCTION is the expression that the user gave to the toplevel call to MAP. And it's that expression that you want to run. Therefore, we should evaluate the variable reporter, not encapsulate it in a lambda.

The goal is that unsophisticated users should be able to use and write higher order functions with minimal emphasis on anonymous procedures. Snap! should just "do the right thing" for such users.

And yes, there are very occasional cases in which someone really does want to ringify a variable that's the input to CALL or MAP, but they really are quite rare, and the people who write code like that are sophisticated Snap! users who know about "ringify."

Except for ASK. In ASK it's common to want to know the value of a variable in the other sprite. So maybe we should have a special case for ASK and not unringify variables in the ringed input. (Just ASK, not TELL, because a variable reporter is an expression, not a script, so it's not a valid input to TELL.) Or maybe we should make the special case even more special by not unringifying only if the variable is a sprite-local one?

On the other hand, you can get the value of another sprite's local variable directly by using the OF block in Sensing. Once you've selected the sprite in the right pulldown, the left pulldown will include that sprite's local variables.

10

what if ASK doesn't unringify for Sprite-local variables, but does unringify otherwise?

In terms of the shape of the thing that is dragged into the ASK, oval could mean variable, or non-predicate reporter builtin/custom-block. I assume though the code underneath knows the difference? Or is a variable technically a reporter block as well?

11

Yeah, a variable block is just a particular case of a reporter.

12

Interesting. So Make a Variable is just a shortcutted workflow for making a custom reporter block, and Set Variable acts on the actual value/reference passed out of the reporter (to use C++ terms, I forget the way Snap! likes to call that)

13

Looking at the OF block, don't have time to test now. I'll be looping through MY neighbors, and the sprite will be in a loop variable, seems like OF might not know until runtime what sprite is in that variable and what local variables are available

14

Yeah, I think if the sprites are going to be clones of a particular sprite you can put that one on the right, then select the variable on the left, then replace the right operand with the variable holding the particular clone of interest.

15

Well, yeah, except that historically Make a Variable came long before custom reporters!

16

Well thanks, I certainly understand better. I'll be able to explain to my students, if you try to just ask a clone for its sprite-local variable, you have to re-ringify. But if you ask the clone what it gets when it runs a reporter block, you don't have to re-ringify.

And that hopefully will provide motivation to code accessor reporter blocks, stand up something more like an Interface.

17

What about only removing rings when the variable is almost completely covers the ring, and not removing rings when it's a bit down and to the right?

18

Oh gosh, we had a thing like that in BYOB 3, and people found it horribly confusing. Not specifically about variables; you could ringify or not ringify any expression depending on exactly where you dropped it.

19

Yeah, not my call wrt user experience, but variable behavior depending on precise dropping position sounds confusing and difficult.

I think holding a key like shift or alt or ctrl while dropping might make more sense.

But I think it would make most sense to de-ringify only all-sprite variables, let this-sprite-only variables remain ringified.

20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.