Poking Splices and Voids Into Series Positions

Usage Feature Discover
1

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: ()
== \~,~\  ; antiform (ghost!) "void"

>> list
== [a d f c]

() is just a particularly handy way of making voids; note NONE and VOID do the same thing here:

>> list.2: opt all [1 = 1 2 = 2 'x]
== x

>> list
== [a x f c]

>> list.3: pack []
== \~()~\  ; antiform (pack!) "heavy void"

>> list
== [a x 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: ()
== \~,~\  ; antiform (ghost!) "void"

>> text
== "adfc"

There's lots of good in the new architecture. Expect to see historical woes vanish, and more new features...

1 Like
Solving the Pox of the (^)... LIFT the Universe?
2

One might ask if VOID should opt out of the assignment entirely, when "opt-in-nothingness" is already covered by NONE (empty splice):

e.g. why not make it:

>> list
== [a d e f c]

>> list.3: spread []
== \~[]~\  ; antiform (splice!) "none"

>> list
== [a d f c]  ; works like this today

>> list.1: none  ; also exists by name
== \~[]~\  ; antiform (splice!) "none"

>> list
== [d f c]

>> list.2: ()
== \~,~\  ; antiform (void!)

>> list
== [d f c]  ; possible alternative "no-op" interpretation

That would give you a way to "opt out" of the assignment, in addition to 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 SPLICE! using non-^META assignments (e.g. MAP!).

That requires an unstable antiform. We could invent an ERROR! with this meaning, but today an empty pack or comma antiform are used.

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... (that might make more sense for using a weird error).

1 Like