sl0ppty: a shader's strength can be an expression

Adding an effect meant writing C -- in the binary, or since D15 in a shared
library. Both are a lot of ceremony for "dim every other row".

So: `amount` may be an expression, compiled to bytecode when the config is
read and evaluated per cell.

    shaders {
        dim  amount="(y % 2) * 40"                       // scanlines
        dim  amount="(x > cols - 10) * 120"              // a right margin
        tint amount="255 - dist(x, y, curx, cury) * 12" color="#ff5fd7"
    }

The scope is the argument, and that is the whole design. Every built-in here
is already colour_op(amount) with the amount a pure function of position --
vignette, zebra, ruler, margin and spotlight differ only in that function --
so the part worth handing to a config is the *number*, not the colour maths.
Three things follow at once: the mixing stays in C where it is fast and
correct; an expression cannot produce an invalid cell, because it produces
one byte; and that byte is cacheable.

The cache is what makes an interpreter affordable, and the numbers are why
this exists at all. Measured on a 200x50 pane, one pass:

    native vignette                  6.1 ns/cell
    constant expression, folded      5.6 ns/cell
    positional expression, mapped    5.2 ns/cell
    animated (reads the clock)      35.0 ns/cell

A shader you wrote in your config costs what a compiled one does. A program
that does not read the clock is evaluated once per cell into a byte map and
reused until something it reads changes; one that does read the clock is
interpreted per cell, per frame, which is the honest price of animation and
is opt-in. (The earlier measurement of 56ns for interpretation was per
evaluation -- correct, and the reason the map exists rather than an argument
against the language.)

What a program reads is derived by the compiler rather than declared, and
that dependency set *is* the cache key. A stale map is therefore
unrepresentable rather than merely unlikely -- the same rule the layout
follows, arrived at from the other direction. A unit test caught the first
violation of it before anything else did: `cols` and `rows` carried no
dependency flag, on the theory that the key always contains the rect, and so
a program reading only the size looked constant and was folded at compile
time, where every size is zero.

The language is deliberately total. No loops, no recursion, no jumps: even
`?:` compiles to evaluating both sides and selecting, because nothing in it
has an effect. Evaluation is O(program length), so a config cannot spin, and
there is nothing to sandbox. Division by zero is 0 rather than a trap: an
expression that is wrong should look wrong, not take the session with it. One
that does not compile drops that one shader with a warning -- not the config,
and not the half-strength version of what you asked for, which is what the
number path did with garbage and is now also fixed.

shader_t gained the compiled program, so the plugin ABI goes to 2. A plugin
built against 1 is refused with "shader ABI 1, we speak 2" and needs nothing
but a rebuild -- the check earning its keep the first time it was asked to.

1 files changed, 19 insertions, 0 deletions

diff --git a/README.md b/README.md
index 5a6b982..b365f9c 100644
--- a/README.md
+++ b/README.md
@@ -122,6 +122,25 @@ states {
 The same mechanism draws a column ruler, a margin marker or a spotlight that
 follows the cursor, inside programs that have never heard of such things.
 
+**A shader's strength can be an expression**, so an effect nobody built in
+takes one line of config and no compiler:
+
+```kdl
+shaders {
+    dim  amount="(y % 2) * 40"                        // scanlines
+    dim  amount="(x > cols - 10) * 120"               // a right margin
+    tint amount="255 - dist(x, y, curx, cury) * 12" color="#ff5fd7"
+}
+```
+
+Integer arithmetic over `x y cols rows curx cury focused t`, with `min max abs
+clamp dist` and comparisons that give 0 or 1 — so `(x < 10) * 200` is how you
+write a rule. There are no loops, so a config cannot hang a session. The
+expression produces the *strength* and never the colour, which keeps the
+mixing in C and means the whole program can be worked out once into a per-cell
+map and reused: a shader you wrote in your config costs about what a compiled
+one does.
+
 **You can add your own** without rebuilding sl0ppty: a shader is a C function
 from one cell to that cell's colours, and any `*.so` in
 `~/.config/sl0ppty/shaders/` that exports one is loaded at startup and named