Exprerements with ringifyed text (wip)

I found a few thing about ringified text, but first you should probably know;

What is ringifyed text?

Ringifyed text is half a glitch but more of an exploit, it is created by setting
an“unveiled any” input and making it report the input, but typing text in you can get text inside a ring!
untitled script pic 17

The basics

By dragging the reporter bubble you can get said ringifyed text as a block

Trying to call a ringifyed text doesn’t work as you would expect, it just reports the ring with the text inside not the text inside the ring as a string

It behaves like an empty ring, you can’t drag the input outside of the ring, it’s stuck inside

Some more properties
The text inside the ring can be edited by just clicking on the input, in fact the ringed text works identically to an “any unveiled” input itself, so it’s a separated block input

This is still a work in progress, more coming soon!

Is there a functional purpose to this block, or is it just for fun?

Not sure exactly so far

From what I see it’s the input itself inside of a ring
That explains why you can never call it because it just, reports another ring around itself

I’m currently attempting to get it to work with lists but it never works

You can’t use the block with call inputs that’s why it’s weird
untitled script pic 18

It's quite consistent and works exactly as as expected
untitled script pic (10)
untitled script pic (11)

That’s because you are using the call block on the input
To get ringifyed text you can’t call the input you have to report it directly
Like this
untitled script pic 19

It’s somewhat had to experiment with because no matter what you do you cannot put anything apart from manually typed text in the input slot, other wise it just reports what’s inside even if you call it on the outside

Spot the difference ...
untitled script pic (21) <> untitled script pic (20)


untitled script pic (22)

untitled script pic (23)

Perfect! Now I can exparemenet more, does th calling work with a block in the slot too?

Nvm we need to report the ring itself not the things inside the ring

You can also get ringed Boolean switches by using the unevaluated Boolean input type.

It's Any (Unevaluated) not Any (Unveiled)

... and the word isn't just arbitrary. If you understand why it's called "unevaluated," you won't find the behavior so mysterious.

Ordinarily, like most but not all programming languages, Snap! evaluates the inputs to a procedure before calling the procedure itself. That is, when you say
untitled script pic
procedure FOO knows that the value of its input is 5, but it doesn't know how that input was computed. It doesn't know that there's an addition involved; as far as FOO is concerned, it would make no difference if the expression were
untitled script pic (1)
This evaluation rule (evaluate inputs first) is called "applicative order evaluation."

But Snap! allows exceptions to this rule. A procedure can say that it wants to get the expression for an input rather than that input's value when called.

In Snap!, how do we make an expression available as data? Right, we put a ring around it. The usual way to do that is to declare the input to be of type Reporter, so we have
untitled script pic (2)
untitled script pic (3) untitled script pic (4)

(This is generally more useful if the input expression has an empty slot, so that it can be re-evaluated with a different input each time, e.g.,


Again, to get this behavior, you declare the input to be of type Reporter. That includes a ring in the block, into which you can drag an expression; you don't have to explicitly ringify the expression.

But sometimes you want to build a control structure that doesn't rub the user's nose in the fact that there's a procedure involved. The classic example is
untitled script pic (6)
This is now a primitive, but originally we wrote it in Snap!. Here was our first effort:
untitled script pic (7)

Why do the YES and NO inputs have to be ringed?

Think about writing a recursive function, such as factorial:

So now we step through the computation of (FACTORIAL 3) supposing that YES and NO are ordinary inputs, computed before FACTORIAL is called. The IF reporter looks like this:

The THEN input expression is just 1, and its value is 1. The ELSE input expression, though, is (N × (FACTORIAL (N − 1))). Since N=3, the value of this expression is (3 × (FACTORIAL 2)). So before we can finish computing this input, we have to evaluate (FACTORIAL 2).

So, the THEN input is 1, and the ELSE input is (N × (FACTORIAL (N − 1))). So we have to compute (FACTORIAL 1).

This time, the THEN input is 1, and the ELSE input is (N × (FACTORIAL (N − 1))). So we have to compute (FACTORIAL 0).

This time, the THEN input is 1, and the ELSE input is (N × (FACTORIAL (N − 1))). So we have to compute (FACTORIAL -1).

This will go on forever, computing (FACTORIAL -2), which requires (FACTORIAL -3), and so on.

The reason this doesn't actually happen is that the THEN and ELSE inputs are ringed, and only one of them will actually be evaluated by CALL.

If YES and NO are declared as type Reporter, the block ends up looking like this:
untitled script pic (11)
We can testify that students find this confusing. Also, you can't type a 1 into a ring. For both those reasons, we want the input slots to look like ordinary (evaluated) inputs, but behave like ringed (unevaluated) inputs. This is what "Any (unevaluated)" means.

Now go back through all your experiments, and explain why each of them does what it does. :~)

Yes, but is the thing in the ring, the input itself? Or just text?

It's not text, but it's code.

untitled script pic (2) untitled script pic (3)

Does that answer the question, or am I misunderstanding what you're asking?

I think @cookieclickerer33 was asking about the result of untitled script pic 17.

If you drag the "ringified text" procedure outside the report bubble to get it as a block and try to call that, it reports the ringified text instead of the text inside and behaves as the identity function inside map. I think this is a legit bug :slight_smile:

There seems to be an inconsistency with the handling of the empty, unevaluated input parameter.
untitled script pic - 2023-05-10T022436.042
untitled script pic - 2023-05-10T021546.715
untitled script pic - 2023-05-10T022422.033

untitled script pic - 2023-05-10T022313.874
untitled script pic - 2023-05-10T022309.626
An empty, unevaluated input is not substituted when called.
untitled script pic - 2023-05-10T022311.923

Oh. Well then I don't understand the difference between "the input itself" and "just text" when the input is text! :~/