[endgame]

The lens library has a reasonably consistent visual language baked into it:

- Operators containing `%` apply a function to the target (mnemonic: % is "mod" in many languages).

- Operators containing `=` have a `MonadState` constraint and operate on the monadic state.

- Operators containing `~` operate directly on values.

- Operators starting with `<` pass through the new value.

- Operators starting with `<<` pass through the old value.

- Operators containing `@` operate on indexed optics (mnemonic: indices tell you where you are "at" in the structure you're traversing).

So an operator like `(<<<>=)` means "semigroup append something in the monadic state and return the old result". This is the power of a well-chosen symbol language, and I don't know how you'd do this ergonomically and compactly with only named operators.

[secondaryacct]

You wouldnt make it compact, so the new dreaming intern joining your codebase would be able to gloriously produce changes rapidly and get hired under the well intentioned smiles of the rest of the team.

Instead, in the kdb team I joined recently (a one-letter, symbol heavy language used by quants), nobody can remember what things do, nobody has time to teach you the insanity of code older than 2 months, and you re instead spending weeks "learning" under the heavy sighs of everyone suffering from the new burden guy.

Why do you want to do things compactly rather than with clarity?

I wish google could search for one-letter language specific symbol so I could ask "what does -9! do on type J vs type C" (nonsensical exemple, I cant remember types without looking at the type table, but I think -9! transforms a bit array into an object)

[nine_k]

Look, the parent comment lays out a regular dictionary that allows to unpack a symbolic name into words, or pack words into a symbolic name.

In your case, the vocabulary is absent. (And yes, the custom of naming K functions with numbers, especially negative numbers, is sort of annoying.)

[andrewl-hn]

I think the K team recognized these issues and tried to address them - at least partially - with Q and it's readable function names and SQL-like extensions. But, AFAIK most Kdb programmers keep writing straight K instead. Don't know why either.