I'm tidying up SET and GET to run on a common infrastructure based on PICK and POKE (generalized via isotopes and "dual representation"). It's quite nice!
As I go, I'm improving things left and right. The POKE handler is now built on the same code as CHANGE, with a :PART of 1. That means you can do things like this:
>> list: [a b c]
== [a b c]
>> list.2: spread [d e f]
== \~(d e f)~\ ; antiform (splice!)
>> list
== [a d e f c]
>> list.3: void
== \~[]~\ ; antiform (pack!) "void"
>> list
== [a d f c]
Since strings can't store lists in them, you don't have to "spread" strings to splice them...
>> text: "abc"
== "abc"
>> text.2: "def"
== "def"
>> text
== "adefc"
>> text.3: void
== \~[]~\ ; antiform (pack!) "void"
>> text
== "adfc"
There's lots of good in the new architecture. Expect to see historical woes vanish, and more new features...
1 Like
One might ask if VOID should opt out of the assignment entirely, when "opt-in-nothingness" is already covered by BLANK (empty splice):
e.g. why not make it:
>> list
== [a d e f c]
>> list.3: void
== \~null~\ ; antiform
>> list
== [a d e f c]
>> list.3: blank
== \~()~\ ; antiform (splice!) "blank"
>> list
== [a d f c]
That would give you a way to "opt out" of the assignment, as well as a way to "opt in" but assign nothing.
However... we have to have some way to ask for "remove entirely".that generalizes to places that can meaningfully store BLANK! (e.g. MAP!).
That requires an unstable antiform. We could invent an ERROR! with this meaning, but today an empty pack is used. My instincts tell me not to try and do this with something besides OPT.
Maybe there's another way to "un-ask" for a SET/POKE, and keep the code going without doing it. I'll think about it...
1 Like