lynn's house

Late acceptance hill-climbing, a snake with a camera

Sat, 13 Jun 2026 00:00:00 +0000

It’s a Saturday morning, and suddenly I wonder: what’s the most compressible list of eight distinct 8-letter English words? Let’s write some Python code.

import random, re, zlib

words = open("/usr/share/dict/words").read().split()
words = [w for w in words if re.match("^[a-z]{8}$", w)]
N = 8

def compress(w):
    return zlib.compress(" ".join(w).encode("utf-8"), level=9)

w = random.sample(words, N)
print(len(compress(w)))  # How small can this get?

Minimizing the “cost function” len(compress(w)) is an “optimization problem” with a large search space: there are 12,529 candidate words, which means over 6 × 10³² lists-of-eight-words to consider.

We’re going to compare some increasingly clever approaches for exploring this search space:

Trying random stuff
Undirected local search
Hill climbing
Simulated annealing
Late-acceptance hill climbing
Conclusion

Each code blog in this post is a standalone Python script, so you can follow along at home easily. In fact, I encourage you to type out the code examples by hand: the ideas in the post will stick with you better than if you were to simply read along, or clicked “play” on a notebook.

On Arch, I had to yay -S words, but other Linuxes (and Macs, I think) come with /usr/share/dict/words pre-installed. If not, you can get the word list here and update the path.

Trying random stuff

We might try random sets of words and see how well they compress. Whenever we beat our record, we’ll print the result.

import random, re, zlib

words = open("/usr/share/dict/words").read().split()
words = [w for w in words if re.match("^[a-z]{8}$", w)]
N = 8

def compress(w):
    return zlib.compress(" ".join(w).encode("utf-8"), level=9)

best = random.sample(words, 8)
best_cost = len(compress(best))
print(f"({best_cost}):", *best)

while True:
    attempt = random.sample(words, 8)
    cost = len(compress(attempt))
    if cost < best_cost:
        best = attempt
        best_cost = cost
        print(f"({best_cost}):", *best)

On my computer, this prints something like…

(68): puniness reverted scavenge critical haymaker cowlicks hankered relaunch
(67): stranger platters betiding skincare advanced resuming bourbons seizures
(66): crisping sleekest lovelorn stuffily pirating estrogen gargoyle vagrants
(65): shebangs tarragon doorpost coleslaw prequels japanned dispirit maternal
(64): adducing splodges motorman weddings enticing collages darlings pervades
(61): poisoned suspense tousling elisions discuses sheepish ogresses snippier
(60): blocking trucking booklets trekking billings quipping preciser bombings
(59): caroling scooting spooning surefire clouting flouting cackling wonkiest

and then stalls. I guess the many -ing words are working well for compressibility, but it’s hard to arrive at such a set by pure chance.

Undirected local search

Instead of creating new attempts from scratch every time — picture throwing darts into the search space at random — we can “walk around” the search space, constantly moving from the current state to a “nearby” state in some sense. This idea is called local search.

What might that mean for us? If we have a candidate list of compressible words w, how do we tweak it to find another candidate? Let’s try replacing one word at a time, swapping words between w and the rest of the dictionary. To make this convenient, we can permute the big words list itself, and say that words[:N] is current list-of-eight under consideration, while words[N:] contains all other words. Then a “step” involves simply swapping elements between these two sides of the array:

i = random.randrange(0, N)
j = random.randrange(N, len(words))
words[i], words[j] = words[j], words[i]

Here’s our full code again. Try running it yourself.

import random, re, zlib

words = open("/usr/share/dict/words").read().split()
words = [w for w in words if re.match("^[a-z]{8}$", w)]
N = 8

def compress(w):
    return zlib.compress(" ".join(w).encode("utf-8"), level=9)

random.shuffle(words)
best = words[:N]
best_cost = len(compress(best))
print(f"({best_cost}):", *best)

while True:
    # Randomly swap out a word
    i = random.randrange(0, N)
    j = random.randrange(N, len(words))
    words[i], words[j] = words[j], words[i]

    # Did that improve things?
    cost = len(compress(words[:N]))
    if cost < best_cost:
        best = words[:N]
        best_cost = cost
        print(f"({best_cost}):", *best)

With this change, instead of “throwing darts” at search space, we are stumbling through it randomly. We can see words sticking around between improvements now, especially at the beginning.

(68): tattooed smirches revivify hoarding squarest cowlings unfasten locators
(67): tattooed smirches revivify hoarding squarest cowlings cabochon locators
(66): tattooed mediates trenches hoarding squarest cowlings misusing locators
(65): overhung mediates consoles hoarding probates retained misusing centrism
(63): derriere acrobats marketer balsamic slighted rotation crappers threaten
(62): milepost scantest snugging paranoid parasols plotting spoiling unburden
(61): pointing rambling bleeping eruption sureness nosiness prairies mistreat
(60): singular pureeing choicest squarest grasping chroming testiest mechanic
(59): pleasing grapples gritters relaters toasting resoling paneling shoehorn
(58): defiling tricking swagging heisting sledding haunting mounting dentists
(56): releases tracking shacking stapling snacking stemming demising primness

But can we really expect this approach to do much better than the “fully random” approach? We are printing results that are better than anything we’ve seen, but we’re not letting that comparison guide our search at all yet. We may stumble back out of a promising region of search space just as easily as we stumbled into it. Let’s find some way to improve on this.

Hill climbing

A simple way to guide a local search is called hill climbing: only commit to those random steps that are direct improvements. If we imagine the problem space as a landscape where better solutions (lower cost) are “higher up”, we only take steps uphill.

To implement it, we only need to append this little bit to our code…

    else:  # If this swap *isn't* an improvement...
        words[i], words[j] = words[j], words[i]  # undo it

Now the behavior of our program is very different! Here are three different runs:

(66): bendable beginner cesspool northern selloffs showoffs massacre druggies
(65): bendable beginner asphodel northern selloffs showoffs massacre druggies
(64): bendable beginner asphodel northern selloffs fusspots massacre druggies
(63): bendable beginner asphodel northern selloffs fusspots massacre embroils
(62): bendable occupies asphodel northern selloffs fusspots massacre embroils

(66): eremites sciences nuisance spawning polecats lacrosse globulin chancels
(65): eremites sciences nuisance spawning polecats lacrosse trapdoor chancels
(64): eremites sciences nuisance spawning polecats lacrosse trapdoor mealiest
(62): eremites sciences nuisance screened polecats lacrosse trapdoor mealiest
(61): eremites sciences nuisance screened neurosis lacrosse trapdoor mealiest
(60): eremites sciences nuisance screened neurosis lacrosse landmine mealiest
(59): eremites sciences nuisance screened neurosis lacrosse landmine addendum
(58): eremites sciences nuisance screened neurosis lacrosse landmine lecterns
(57): eremites sciences nuisance screened schussed lacrosse landmine lecterns

(67): emerging insignia bronzing diazepam berating discoing shakeups killjoys
(65): emerging diuretic bronzing diazepam berating discoing shakeups killjoys
(63): emerging diuretic bronzing diazepam berating discoing shakeups iambuses
(62): emerging diuretic bronzing diazepam berating discoing gestated iambuses
(61): emerging diuretic bronzing diabetes berating discoing gestated iambuses
(60): emerging diuretic bronzing diabetes berating discoing disorder iambuses
(59): emerging diuretic bronzing diabetes berating discoing disorder bartered
(58): emerging diuretic denuding diabetes berating discoing disorder bartered
(57): emerging guarding denuding diabetes berating discoing disorder bartered
(56): deriding guarding denuding diabetes berating discoing disorder bartered
(55): deriding guarding denuding recorder berating discoing disorder bartered
(54): deriding acceding denuding recorder berating discoing disorder bartered
(53): receding acceding denuding recorder berating discoing disorder bartered
(52): receding acceding denuding recorder berating discoing disorder beriberi
(49): receding acceding aerating recorder berating discoing disorder beriberi
(48): receding acceding aerating recorder berating seceding disorder beriberi
(47): receding acceding aerating suborder berating seceding disorder beriberi

The third time, we beat our fully-random attempts by a wide margin. But the first two times, we were unlucky, and we got stuck at a local optimum. The hill we randomly decided to climb was not the highest hill in the landscape.

Even in the third run, we have the “odd pair” of -order words in the result we land on, breaking the -erating and -ceding pattern. Improving further on the whole set means first making the backwards step of getting rid of one of them. This is the big problem with “naive” hill climbing.

So, we’d like a less headstrong local-search algorithm, that will take steps downhill sometimes: often enough to help it discover higher hills in the landscape, but not so often that it fails to be sufficiently attentive or attracted to them.

Simulated annealing

I really like this animated GIF from the Wikipedia article on simulated annealing:

It shows a one-dimensional “hilly landscape” with plenty of local optima to get stuck on. What is this algorithm doing to find the highest hill? From looking at the GIF, we can already try to form an intuition. A temperature value is ticking down steadily. When it’s high, the red line moves erratically, accepting almost any step towards a new state. As the temperature goes down, the red line chills out, and becomes less likely to jump away.

Indeed, simulated annealing boils down to this:

Set some initial temperature T, and slowly tick it down to 0 as you search.
Always accept “uphill” steps with cost < best_cost.
Accept a step “downhill”, i.e. with cost > best_cost, randomly with probability exp(-(cost - best_cost) / T).

Why this function? The graph of f(x) = exp(-x / T) slopes down from 1 at x = 0 to 0 as x → ∞, with T controlling the steepness of the slope. (Play around with it in Desmos!) This gives us what we want: an infinitesimally small step down x is acceptable at any temperature, but as T goes up, we become quicker and quicker to reject a step down by any larger x.

The name annealing comes from metallurgy: it refers to treating a material by heating it up a bunch and then slowly cooling it down at just the right pace.

This box is blue, which is the color of apologies. I apologize for mixing metaphors! People write about optimization problems in two directions: maximization and minimization. There’s the “hill climbing” metaphor, like in the GIF, which makes the most intuitive sense when you’re maximizing a score: “higher” means “better”. But simulated annealing is often described in terms of minimizing a cost, as we have it in our word-compressing problem: going “uphill” in the language of hill-climbing means going down in cost.

Here’s simulated annealing in a Python script:

from math import exp
import random, re, zlib

words = open("/usr/share/dict/words").read().split()
words = [w for w in words if re.match("^[a-z]{8}$", w)]
N = 8

def compress(w):
    return zlib.compress(" ".join(w).encode("utf-8"), level=9)

random.shuffle(words)
current_cost = len(compress(words[:N]))
best, best_cost = words[:N], current_cost

T = 2
while T > 0:
    # Randomly swap out a word
    i = random.randrange(0, N)
    j = random.randrange(N, len(words))
    words[i], words[j] = words[j], words[i]

    # Accept the swap if it's uphill, or the temperature randomly allows it.
    new_cost = len(compress(words[:N]))
    p = 1 if new_cost < current_cost else exp(-(new_cost - current_cost) / T)
    if random.random() < p:
        current_cost = new_cost
        if current_cost < best_cost:
            best, best_cost = words[:N], current_cost
            print(f"({best_cost}):", *best)
    else:
        # Otherwise, undo the swap
        words[i], words[j] = words[j], words[i]

    T -= 0.000001

It’s immensely successful, reliably finding solutions about as good as this one:

...
(37): winching pinching cinching parching munching patching punching bunching
(36): hunching munching mulching matching hatching patching punching mulcting
(35): latching patching bitching watching pitching witching hatching ditching

or this one:

...
(37): clinging flinging slinging bringing fringing tingling bridling ringings
(36): slinging clinging swagging clinking clogging swinging slogging slinking
(34): slinging clinging cringing clinking stinking stinging clonking slinking

The sad news is that to get the program to this point, I had to tweak the initial temperature (2) and step size (0.000001) until the results were any good. This is called hyperparameter optimization and nobody likes it, especially when there are many parameters to finetune before you get any promising results — which is sadly the case for simulated annealing.

Late-acceptance hill climbing

There is a brilliant alternative with a very short Wikipedia article called late-acceptance hill climbing. It’s so simple: we keep track of the last L costs, and accept a step if it’s at least as good as the current state or as what we had L steps ago. We can use a circular buffer (let’s call it history) to implement this:

import random, re, zlib

words = open("/usr/share/dict/words").read().split()
words = [w for w in words if re.match("^[a-z]{8}$", w)]
N = 8

def compress(w):
    return zlib.compress(" ".join(w).encode("utf-8"), level=9)

random.shuffle(words)
current_cost = len(compress(words[:N]))
best, best_cost = words[:N], current_cost

L = 40
history = [current_cost] * L  # the last L costs; starts all-equal
step = 0

while True:
    # Randomly swap out a word
    i = random.randrange(0, N)
    j = random.randrange(N, len(words))
    words[i], words[j] = words[j], words[i]

    # Accept if it beats where we are now, or where we were L steps ago.
    new_cost = len(compress(words[:N]))
    v = step % L
    if new_cost <= current_cost or new_cost <= history[v]:
        current_cost = new_cost
        if current_cost < best_cost:
            best, best_cost = words[:N], current_cost
            print(f"({best_cost}):", *best)
    else:
        words[i], words[j] = words[j], words[i]  # undo

    history[v] = current_cost  # remember where we are now
    step += 1

There is only one hyperparameter to tweak, namely the size of history L. This choice of 40 gives me excellent results:

...
(35): wracking slacking stinging sticking stinking snacking stacking slinging
(34): blacking slacking stinging sticking stinking swinging stacking slinging
(33): blacking slacking stinging sticking slicking slinging stacking stinking

Try running it yourself and tweaking the parameter yourself.

I don’t have a great intuition for why this works well, but I did think of a nice visualization. In the video below, the state space is a blobby image, and a “snake” is wriggling around, looking for the brightest pixel. The yellowest blob contains the global optimum. The white circle is the snake’s head, the white square is a “camera” attached to the tip of its tail.

The snake’s head will move to a new nearby spot if it’s at least as bright as what either its head or the tail camera sees; otherwise it stays in place. (The little red lines are where it’s deciding not to move.) The parameter L is the length of the snake.

Conclusion

I just really like late-acceptance hill climbing. If you have a search problem with a big state space, give it a try!

Oh, and the most compressible word list is probably something like blacking slacking stinging sticking slicking slinging stacking stinking, which compresses to 33 bytes. But who knows? An important takeaway is that none of these approaches promise to find the perfectly optimal result. Often, an approximate optimum is good enough.

Can you find a better list of eight words? Let me know on Bluesky.

Adding compose key rules from the clipboard

Fri, 12 Jun 2026 00:00:00 +0000

I wrote a small Bash (plus Python) script for adding my current clipboard contents to my compose key.

It’s made for my combination of GNOME + Wayland + XCompose + ibus, so you may have to tweak it. But here’s the idea:

#!/usr/bin/env bash

symbol=$(wl-paste)

code=$(zenity --entry --title="Adding compose rule from clipboard" --text="Which keys should make '$symbol'?")
if [[ -z "$code" ]]; then exit 1; fi

keys=$(echo "$code" | python -c 'names=["error"]*32 + "space exclam quotedbl numbersign dollar percent ampersand apostrophe parenleft parenright asterisk plus comma minus period slash 0 1 2 3 4 5 6 7 8 9 colon semicolon less equal greater question at A B C D E F G H I J K L M N O P Q R S T U V W X Y Z bracketleft backslash bracketright asciicircum underscore grave a b c d e f g h i j k l m n o p q r s t u v w x y z braceleft bar braceright asciitilde".split(); print(*["<" + names[ord(c)] + ">" for c in input()])')

echo "<Multi_key> $keys : \"$symbol\"" >> ~/.XCompose

ibus restart

That nasty-looking Python command translates ASCII symbols to their .XCompose-safe key names. For example, o/ becomes <o> <slash>.

I put this script at ~/.local/bin/addcompose and hooked it up to Super+Shift+A in GNOME Settings:

Here it is in action:

Now I can hit CapsLock m t to type ↦. Yay!

NetHack 5.0.0 (is still guidecore)

Sat, 23 May 2026 00:00:00 +0000

NetHack is the strangest game that I regularly get sucked back into. Recently, the DevTeam released version 5.0.0. The version I’m most familiar with is 3.4.3, which seemed to be the “definitive” version when I started playing as a teenager (c. 2008) and development had already long slowed to a crawl.

I long considered the changes in 3.6.0 and beyond to be a bit disappointing: they mostly served to remove cheesy strategies from 3.4.3 that I found fun. So I lost interest for a while, until the recent release of a major version (the first since the 1980s!) made me check in with the DevTeam’s progress.

Many of the recent changes diversify winning strategies, make the late game more interesting, and remove “interface screw”. For example, the game now prevents you from instantly dying if you accidentally typo your way into a pool of lava. Mind flayers’ attacks no longer cause you to forget maps and items, which encouraged the highly un-fun chore of making backup notes outside of the game.

Goodbye, chordbug the Demigoddess

I won as an orcish Barbarian, playing on nethack.alt.org, a Telnet server that has hosted NetHack since 2001. Apparently, the last game I played on this account, in 2019, was also an orcish Barbarian win. Oops! I should have changed it up.

Some of the most obvious changes in NetHack 5 are interface modernizations. Dungeon branches are colored now, which is lovely. Hell is wrought of fiery rock and iron, and Sokoban is blue, the color of thinking. I messed up a Sokoban level because they are randomly mirrored now, which screws with my muscle memory. I’m not sure what the point of the change is but I think it might have worked on me.

I wonder how the DevTeam reasons about exposing vs. hiding information from the player. For example, NetHack has a weirdly “secret” defensive stat called magic cancellation, not to be confused with magic resistance. Roughly speaking, MC defends against magical “touches” whereas MR wards you from ranged spells. It used to be that the cloak of MR also provided maximal MC, but this is no longer true. (I got level-drained many, many times.) This well-intentioned balance change seems to make it much more important to think about MC… but its existence remains well hidden. I think it would have been good to present MC next to AC in the status bar. Or would that ruin the magic?

Throughout my adventure, I realized the NetHack wiki is a bit of a mess. It was written for 3.4.3, and now contains a bunch of outdated information, with updates for later versions straddled between callout boxes and actual edits to the body text. But really, it has always contained a bunch of ultra-detailed cruft that is not so relevant to most players. (The article about Vlad has an entire section dedicated to taming him, which is something roughly zero percent of players will ever try to do.)

On “guidecore”

I find NetHack hard to recommend to anyone, but it has a special place in my heart. To master NetHack is to memorize reams of dumb little facts and interactions that you can use to your advantage. This ascension marked the first time I ever used the nugget of wisdom that you can dip an amethyst into booze to make fruit juice — because, see, fruit juice was randomly smoky in my game, and drinking a smoky potion has a 1/13 chance of summoning a djinni, which in turn rolls for a 4/5 chance of getting to wish for any item in the game — as long as the potion is blessed, of course. Its baroque complexity makes the original Rogue look like Spider Solitaire.

Winning NetHack without a guide or wiki seems unrealistic. Then again, NetHack inspired Minecraft, which is rather like that too, and it’s the best-selling video game of all time. The harsh unknowability of these games becomes their appeal, inspiring all sorts of walkthroughs and tutorials. I’m reminded of The Tower of Druaga, an arcade RPG that asks the player to master its obtuse secrets: Japanese players exchanged hints in notebooks to beat the game, granting it cult status in the progress.

There ought to be a name for this school of game design. Guidecore, maybe? Tell me about your favorite guidecore games.

Some Strudel tips

Sun, 15 Feb 2026 00:00:00 +0000

I’ve been doing a bunch of livecoding/algorave stuff in Strudel, and it’s great fun. You can make all kinds of fun sounds through experimentation, and the docs are fantastic, but I’ve been itching to make a kind of “guide” that catalogues certain winning formulas for electronic music that I frequently turn to.

Here are some scattered thoughts that would make it into such a guide. Each code block is executable: press Ctrl+Enter to start audio and Ctrl+. (period) to stop.

Hi-hats

Many “house-y” rhythms sound good with hh*16. Just don’t make them too loud. It sounds good to play them “softly, then a bit louder” on each beat.

(Also, claps and snares like to be on beats 2 and 4.)

Ribbon

If you play random notes in a scale, it sounds, well, random. But if you loop a single random measure, it will start to sound like music! In the words of Adam Neely: repetition legitimizes. In Strudel, the ribbon function .rib can slice out a bit of a (random) pattern and loop it.

You can even do things like .rib("52 52 52 <52 3>", 1) to change the pattern up every other bar.

Randomize everything

Most parameters sound fun when randomized over a small range. It can make even a single note sound interesting. Also, randomly pitch notes up or down by an octave! This kind of “accent” with rarely sounds fun.

You can combine this with rib, but you don’t have to.

Chords, bass, drums, melody

This is a solid four-ingredient recipe for making a tune sound “full.”

Try muting parts with _$ to see what it feels like to have “no chords” or “no bass” for a bit. It’s fun to DJ like this.

(Oh! I like this trick for making nice and “full” chord voicings: play the same chords at two different anchors, then pan them left and right.)

Fun samples

There are loads of fun samples in github:tidalcycles/dirt-samples and github:yaxu/clean-breaks.

Meanwhile, github:yaxu/clean-breaks catalogs some nice drum loops for breakbeats.

I like using Vocaloid samples in Strudel… There are some excellent stems licensed under BY-NC-SA on Jamie Paige’s stems page, from which I took the Strawberry vocal for teto in github:lynn/sounds/main/vocaloid.

More?

Maybe that’s plenty of tips for now – I can feel myself veering off track. But I might write more about Strudel in the future. Let me know what you think on Bluesky or email me (lynn@foldr.moe).

Days Since `pacman -Syu`

Thu, 29 Jan 2026 00:00:00 +0000

Sometimes I wake up in a cold sweat and realize it’s been three weeks since I ran pacman -Syu. No more. I use GNOME (btw), so I made a little GNOME shell extension for myself, constantly showing how long it’s been in the top bar.

That 1d means I updated my packages one day ago. If it’s been ten days or more, the number turns yellow.

As far as engineering goes, the process was pretty unremarkable. LLMs make it easier than ever to turn the sparkle of an idea into a single-hour project. The GNOME extensions project has a reasonable no-vibe-coding policy, so I took care to tend to the business logic by hand and trim down the generated fluff.

In this age, a not-too-serious project like this feels like an opportunity to leave a human mark on a program: a silly variable name, or a funny code golf trick that a machine would never generate. Did you know there are 864e5 milliseconds in a day?

You can install Days Since Update here.

Cute beeps for your terminal

Tue, 27 Jan 2026 00:00:00 +0000

I think computers should beep. Put this in ~/.local/bin/bip if you agree:

#/usr/bin/bash

notes=()
times=()
t=0
for arg in $@; do
  if [[ $arg != 0 ]]; then
    notes+=(sine $arg)
    times+=(${t}s)
  fi
  t=$((t + 3500))
done

play -qn -c1 synth 1 ${notes[*]} \
	fade 0.01 0.1 0.06 delay ${times[*]} gain -20

The play command is provided by sox.

Now you can run long_command && bip C4 D4 G4, for example. I use it in my .claude/settings.json to have Claude chirp at me, with different little melodies depending on what it wants.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [ { "type": "command", "command": "bip D5 F4" } ]
      }
    ],
    "Notification": [
      {
        "matcher": "permission_prompt",
        "hooks": [ { "type": "command", "command": "bip D5 E5" } ]
      },
      {
        "matcher": "idle_prompt",
        "hooks": [ { "type": "command", "command": "bip A4 B4 A4" } ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "AskUserQuestion",
        "hooks": [ { "type": "command", "command": "bip D5 E5" } ]
      }
    ]
  }
}

Reader-style Uiua

Sat, 24 Jan 2026 00:00:00 +0000

Lately I’ve been playing with Uiua, an APL-like programming language that has no local variables on purpose. Instead, you describe how data flows through your function using combinators. One can also think of the language as stack-based, though the official documentation has recently started to discourage this perspective.

I appreciate the die-hard commitment to tacit, point-free programming on an aesthetic level, but on a practical level I find it often gets in the way. I’ve landed on a nice way to make programming in Uiua feel more like a regular stack-based language. We can write functions that keep the top-of-stack fixed to some ambient passed-in context, that we constantly either read parts from, or dip past.

Here’s an example of a quadratic discriminant function, Disc(c,b,a) = b²−4ac, side-by-side with what we might write if Uiua had local variables:

Disc ← (           # Disc(C_B_A) ← (
  ~ {C B A}        #
  ⊙ⁿ₂ ⟜B           #   ⁿ₂ B
  ⊙× ⊙4 ⊙× ⟜A ⟜C   #   × 4 × A C
  ⊙-               #   -
  ◌                #
)

We define the shape of the context using a local data definition ~. This context stays on top, and everything underneath it is the effective stack, which starts empty.

Now here’s how we write our code:

Every time we want to read from our context, we use ⟜F to push F(context) to the top of the effective stack.
To manipulate the effective stack any other way, we use ⊙ to dip past the context.
At the end, we pop ◌ the context, leaving only the effective stack values.

I want to call this style reader style, because in a way, this is like programming in a Reader monad: ⟜f is like asks f and ⊙ is like pure or fmap or liftA2. For comparison, here is an equivalent Haskell definition of disc, which is also “point-free without really being point-free.”

import Control.Monad.Reader
import Control.Applicative

data Quadratic =
  Quadratic { c, b, a :: Float } deriving (Eq, Show)

disc :: Reader Quadratic Float
disc =
  liftA2 (-)
    (fmap (^2) (asks b))
    (liftA2 (*) (pure 4) $ liftA2 (*) (asks a) (asks c))

This style can and should be mixed freely with regular flavors of Uiua. For example, ⊙× ⊙4 ⊙× ⟜A ⟜C could be written ⟜(×₄×⊃A C), where we use a small, easy-to-read tacit function as our accessor function.