The Rosetta stone of GET and SET has come together, based on operations that speak in what I call "dual representation".
For the moment, let's just say the baseline function you can use to operate on variables called TWEAK. If you pass TWEAK a lifted value, it acts just like a SET to that value:
>> tweak $x lift 1020
== '1020
>> x
== 1020
>> tweak $x lift null
== ~null~
>> x
== \~null~\ ; antiform
But then there's the "unlifted range" of values. What those do is a work in progress, but use your imagination... e.g. it could be a GETTER function:
>> tweak $x does [print "HI!" 10 + 10]
== \~&[frame! ...]~\ ; antiform
>> x
HI!
== 20
>> type of get $x
HI!
== \~{integer!}~\ ; antiform <-- e.g. GET doesn't see it as an ACTION!
But How Do You "PEEK" a "TWEAK"?
Right now, the trick is that if you pass TWEAK a NULL, then it interprets that as a query of what the state is:
>> tweak $x lift 1020
== '1020
>> tweak $x null
== '1020
But it would be nice if that had a nicer name. I kind of like PEEK... because of its history of letting you look into the secrets of arbitrary magical memory locations from BASIC (e.g. on a Commodore 64)
Yet in that worldview, PEEK complements POKE... and POKE is an established Rebolism that's "not magical"... e.g. it doesn't work in the lifted range... and is a complement to PICK.
Could POKE Be Reclaimed For The "Tweaky Magic?"
POKE is a nicer name than TWEAK, and pairs nicely with PEEK.
PICK might be complemented by something else...? PUT, maybe?
As a refresher: in Ren-C's model, you don't technically need PICK or POKE, since:
pick x y=>x.(y)poke x y z=>x.(y): z
But their existence helps in various cases, e.g. first: specialize pick/ [1] or something like that.
Thinking About It...
For now I'm just using TWEAK to NULL for "peeking" and not giving it a name yet. But, thoughts welcome...