Proposal - a "CELL" iota for one-shot mutability

General Hexcasting chattery.
(get it cause it's like the irc client hyuck hyuck)
alwinfy
Posts: 2
Joined: Thu Dec 01, 2022 11:54 pm

Proposal - a "CELL" iota for one-shot mutability

Post by alwinfy »

Floated this on Discord, but I figured I'd better archive it for posterity.

A fun notion I've been tossing around is the idea of a 'CELL' Iota, which is either empty (holds NULL) or contains a value. CELLs start out empty.

You'd interact with them in three ways:
qwdd Monk's Reflection - Pushes a new empty CELL to the stack. Costs a negligible amount.
awdd Monk's Purification - Turns a CELL into its value, or NULL if the CELL is empty. Free (or costs very little).
ewdd Monk's Distillation - Pops a value, then puts it into the (empty) CELL at the top of the stack; all copies of the same CELL receive this value. Costs a few dust, tops. (Mishaps if the CELL is not empty.)

You could of duplicate CELLs, save copies in foci, etc. and they'd get updated to Purify to the same value after the Distillation. Notably, though, a CELL could only be set once. (If you want mutability, set the CELL to a list of {new value, <a fresh CELL>}, then write a Hex to walk through the chain of lists :D)

Seems they'd open up some interesting possibilities… might be fun to play with ;)
wdewdwwwwedaqedwadwweqewwdw Seen any suspicious casters around here?
User avatar
kristi fristi
Posts: 26
Joined: Mon Dec 12, 2022 7:23 am

Re: Proposal - a "CELL" iota for one-shot mutability

Post by kristi fristi »

pointers? really? jk, I think this would be a really nice addition. This would be a really cool/balanced way to have different systems across the world all pass information to each other. Although the write once aspect would probably mean designing such a system would cause insanity. epic.
User avatar
kristi fristi
Posts: 26
Joined: Mon Dec 12, 2022 7:23 am

Re: Proposal - a "CELL" iota for one-shot mutability

Post by kristi fristi »

actually, I do see a practical problem, which is that the server would have to store the value of every cell. I don't know how much storage space/working memory a cell would take up, but the fact that you could very easily spam cells does seem a bit concerning to me. maybe there could be a limit to the number of cells a caster is allowed to make, with a pattern that again "free" a cell to return null forever (or even mishap if you don't want freeing to be used to convey a bit of extra information so easily).