Help understanding ringify

I'm working on guiding my students through BJC U5L2 disease spread simulation. At one point, clones have to ask their neighbors about their sprite-variables (in the exercise 'infected?', in my introduction, it's just script var 'name')

So I built a little script like this, so students can see a clone recite all of its neighbors' names (as a prelude to using 'tell' to have all the neighbors say their own names)

ringify script pic

When I drag the 'name' variable chip into the ringify, the ringify disappears. Then when I try to run it, there's an error "variable of name 'Bob' does not exist in this context".

If I right-click the 'name' variable chip, and force it to ringify, then it works as I expect.

So what's the deal with ringify anyways? I thought it was for running script-arguments, so if I just want the value of a variable, I would want it not ringified.

The general rule in Snap!, as in most programming languages, is that inputs are evaluated before the procedure is called. So, if you say foo+3, where foo is a variable, Snap! first looks up the value of foo, which will presumably be a number, let's say 8, and then calls the + procedure with input values 8 and 3. The + procedure doesn't know or care where those values came from.

So if you say ASK (item) FOR bob, Snap! will first find the value of bob in the current sprite and then pass that value to ASK.

The reason ASK has that ring in its input slot is that you normally give ASK an expression that you want the other sprite to evaluate. So you have to prevent Snap! from evaluating it before calling ASK.

A variable getter, the orange oval for the variable, is no different from any other input expression; if you want it evaluated in the other sprite, it has to be in a ring.

The real question is, why does the ring disappear if you drag a variable getter into it? And that's because almost all the time, when you drag a variable into a ring, it's because you're writing a higher order function, and the variable contains an expression, and it's that expression you want to use as the input. For example:

  untitled script pic (1)
If you say
untitled script pic
then the value of the input variable EXPRESSION will be the expression X POSITION, and so the ASK will ask each sprite for the value of X POSITION.

So, as I say, that's the usual situation in which someone drags a variable into a ring. But it's not your situation; you really want to send the variable getter to each neighbor as the expression to evaluate it. Thus, you have to undo our special-case no-ring for variables.

thx bh, your use of the term 'variable getter' made the distinction for me that the little icon is not the variable, it is a reporter that returns the (value of the) variable.

What you probably meant to write is 'name', not 'bob', because "bob" is the value that was assigned (by the clone Bob) to its clone-local (for the lack of a better word) (:point_left:1) 'name' variable.

So, the Bob's "clone-local" variable a) has initially inherited whatever value was assigned to it (:point_left: 2) by the parent sprite (if any value at all), b) but then each clone has assigned its own value, such as "bob" in this case, to its own "clone-local" copy of the 'name' variable.

:point_right: (1) I should have probably said "to the clone's copy of the local variable".

:point_right: (2) When I said "to it", I should have said "to the parent's copy of the local variable", I guess.

Well that's kind of the point, 'name' is the name of this sprite-member variable, and 'bob' is an example of a value of the variable. I was confused why (ask neighbor to (say (var)name)) was resolving into (ask neighbor (say (var)bob)). Thinking of the block chip with the variable name on it as not the variable, but a getter function for the variable is helpful to know what to do, but not why that is wrong.

I guess it's interesting to know we can do indirection like that, have a variable that refers to another variable by label, and cause it to be evaluated

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