On quines and "future embedding". Jump iota-based quines with internal context preservation

[Matt6049]

When I came back to Hex Casting, my first warm-up hex was a quine. I ended up on the following solution:

Code: Select all

Introspection
	Consideration 
		Bookkeeper: -
	Hermes Gambit
	Consideration
		Bookkeeper: -
	Numerical Reflection: 4
	Prospector Gambit
	Surgeon Exaltation
Retrospection

(note: I exclusively use consideration embedding, this would likely cause problems if you attempt to mix this with intro/retro embedding, and would require significantly more trouble with Surgeon's exaltation indices. Please treat this post as an argument for the use of consideration embedding.)

The first embed at index 1 is the payload function - the second embed at index 4 is a copy of the quine, without the self-embed.
Constructing this for any arbitrary payload hex would look like this (assuming the payload is read from a focus for this example):

Code: Select all

Introspection
	Consideration 
		Bookkeeper: -
	Hermes Gambit
	Consideration
		Bookkeeper: -
	Numerical Reflection: 4
	Prospector Gambit
	Surgeon Exaltation
Retrospection
Numerical Reflection: 1
Scribe Reflection
Surgeon Exaltation
Numerical Reflection: 4
Prospector Gambit
Surgeon Exaltation

The reason the payload is cast first is because this way, the self-copy only appears on the stack after having evaluated it, removing the need for additional stack manipulation. It is also possible to create a quine through inlining a payload hex, but that would require you to adjust your surgeon exaltation indices to Length Distillation-3.

This is generally enough for regular use, however, I hit a problem while creating a hex for bit stream manipulation - I wanted my hex to consume data, hold on to it between subsequent re-casts and release it all at once on demand. I wanted to avoid creating a mess on my stack, nor did I want to use 20 patterns to achieve this simple purpose.

To achieve this, I started doing more extensive research into Iris' Gambit and iota embeds. In the process, I stumbled onto an application of iota embedding that is simultaneously mindbogglingly simple, yet rather unintuitive until you see it.
If embedding an iota allows it to be pushed onto the stack upon evaluation, can we not do this dynamically with iotas from the stack?

Let's use Thoth's Gambit as an example; the meta-evaluation pattern creates a local copy of the stack for each element over which it's evaluating its pattern list. This is often undesirable behavior, and leads to people removing the stack copy each iteration, i.e.:

Code: Select all

Numerical Reflection: 1
Numerical Reflection: 2
Numerical Reflection: 3
Introspection
	Compass Purification
Retrospection
Mind Reflection
Mind Reflection
Mind Reflection
Numerical Reflection: 3
Flock Gambit
Thoth Gambit

The above results in a list with three duplicates of our eye position, as intended, but also with three duplicates of the stack prior to casting Thoth's Gambit!

Now, the simple solution would be to simply insert everything from the stack into a list, and remove it in each Thoth's iteration. However, there is a better solution for higher element counts; something I decided to dub "future embedding".

Code: Select all

Numerical Reflection: 1
Numerical Reflection: 2
Numerical Reflection: 3
Flock Reflection
Flock Gambit
Introspection
	Thoth Gambit
	Consideration
Retrospection
Jester Gambit
Integration Distillation

You may already realize what I'm trying to do here. Since iota embedding allows an arbitrary iota to be pushed onto the stack upon evaluation, I'm using this to effectively send the list containing our stack into the future after having evaluated Thoth's Gambit. Let's try using this on the previous example.


As you can see, the resulting list does not contain any duplicates of the local stack, and we receive the stack contents afterwards! This can be used for some hijinks with Iris' Gambit.

The way Iris' Gambit functions is that it boxes up the evaluation stack's state into a jump iota, allowing you to use that jump iota to return to evaluating whatever was meant to happen after the Iris' Gambit.
To give a slightly more understandable example, let's try the following:

Code: Select all

Introspection
	Iris Gambit
	Mind Reflection
	Compass Purification
Retrospection
Iris Gambit
Hermes Gambit

What will happen here, in order:
1) We push a list with Iris' Gambit at the beginning, and Mind's Reflection and Compass Purification scheduled to be cast after Iris' Gambit is done evaluating a pattern list, or after we evaluate its jump iota.
2) We cast Iris' Gambit to evaluate the pattern list, pushing a jump iota with nothing scheduled to be cast afterwards (we are currently staff casting, so therefore Hermes' Gambit is not scheduled yet, as we have not drawn the pattern).
3) The pattern list casts Iris' Gambit over the empty jump iota, pushing a jump iota to itself, and jumps out of the pattern list, cancelling Mind's Reflection and Compass Purification.
4) We evaluate the resulting jump iota, returning to the pattern list and evaluating Mind's Reflection and Compass Purification.

We can treat the jump iota as a sort of pattern list - every time we evaluate it, we will cancel whatever we were supposed to do next, and cast whatever it had scheduled at the time of casting Iris' Gambit. However, this pattern list only takes up the space of 1 iota (without add-ons fixing it), and is closed to any form of external modification. We have created a read-only pattern list!

In combination with future embedding, we could very well store other iotas inside of a jump iota as well:

Code: Select all

Introspection
	Iris Gambit
	Consideration
Retrospection
Mind Reflection
Compass Purification
Integration Distillation
Iris Gambit
Gemini Decomposition
Hermes Gambit

We have achieved all of the things necessary for a quine that is closed to modification and contains some internal state. Although there are still places for optimization, my latest research has resulted in the following quine template:

Code: Select all

Introspection
	Numerical Reflection: 2
	Prospector Gambit
	Surgeon Exaltation
	Derivation Decomposition
	Bookkeeper Gambit
	Hermes Gambit
Retrospection

This is, however, only a template. We still need to assemble it and prepare the arguments it requires.
Firstly, it needs some sort of payload prepended to the beginning. Let's create a very basic counter. Even the payload needs a very specific format, though.

Code: Select all

Introspection
	Derivation Decomposition
	Reveal
	Numerical Reflection: 1
	Additive Distillation
	Integration Distillation
Retrospection

This hex expects a list containing its internal context at the end, then takes it out, reveals it in the chat, adds 1 and appends it back to the list.
We're nowhere done yet, though. We need to hand the quine everything on a silver platter in order to minimize the operation count.
It wants to receive a copy of itself as an argument, as well as the initial state of the internal context, but as part of a hyper specific list. Let's stop dawdling and provide these all at once.

Code: Select all

Introspection	//future embed template
	Iris Gambit
	Consideration
	Bookkeeper: -
Retrospection

Introspection	//counter payload
	Derivation Decomposition
	Reveal
	Numerical Reflection: 1
	Additive Distillation
	Integration Distillation
Retrospection

Introspection	//quine
	Numerical Reflection: 2
	Prospector Gambit
	Surgeon Exaltation
	Derivation Decomposition
	Bookkeeper Gambit: v
	Hermes Gambit
Retrospection

This should've given us all the ingredients. Let's assemble them.

Code: Select all

Additive Distillation 	//payload+quine
Additive Distillation	//future embed template+payload+quine
Numerical Reflection: 0
Integration Distillation	//embed initial counter value, or in other
						//words, the internal context for this payload
Numerical Reflection: 2
Prospector Gambit
Surgeon Exaltation	//self embed
Derivation Decomposition
Bookkeeper Gambit: v	//ensure we do not cast the temp storage
Iris Gambit	//finally, create the quine

Here's what it should look like right before casting Iris' Gambit. Now, whenever we cast Iris' Gambit again, it should display the next value in the chat and increment it internally!

This happens with only about 7 operations' worth of overhead (9 if you include the unpacking and re-packing of the internal context, 8 if you embed the numerical reflection). This is marginally worse than a quine, but it offers several useful properties:

1) The elephant in the room, preserving some state internally on each cast. We can provide the initial state and then modify it internally without ever leaking it out onto the stack.
2) The internal state can be eventually retrieved if so desired by casting Charon's Gambit within the payload to interrupt the process of self-copying (not trivially doable with a regular quine with an embedded payload)
3) While idle, the quine will only take up 1 space on the stack (the jump iota)
4) The quine is not implicitly modifiable, and using Hermes' Gambit instead of Iris' Gambit will safely turn the entire quine and internal context into garbage.
5) It does not require the modification of magic numbers as a result of inlining the payload.
6) Because the quine provides all its necessary arguments to itself in two iotas, you may use the third space to provide external arguments between jumps, and retrieve it within the payload in 1 operation (Rotation Gambit). Similarly, you may produce some form of output value and use Rotation Gambit II to rotate it underneath the jump iota.

While I am not yet done developing this template, I believe this should have uses in many situations with rather minimal overhead as compared to all the features it provides. Hopefully the topics covered in this post will come in handy for someone else, too.

[Akumu9K]

This is quite majorly useful, I wonder if you could build a framework similar to OOP using these, it wouldnt be too hard to give them a variable for functions defined inside them to be applied to the state in them, and then outputted