Three more documented rules for a named `shift` offset are unenforced, and one of them crashes the typesetter

[FBumann]

What happened?

Split out of #58, which covered the two rules a named offset shares with a window's width. shift(offset=p) documents four rules plus a sign rule. Two are fixed in #61; these three are not.

1. A negative named offset crashes instead of being refused — the important one

The docs say:

A named offset also carries its sign in the values: lag=-lead is refused, so one row that points backwards says so where the data is read.

walk.py relies on this in two places:

A named offset comes back as its name. It is always backward — the language refuses by=-p, so the direction lives in the data

It is not refused. It loads, and then the typesetter dies:

parameters: { lead: { dims: [unit], dtype: int } }
constraints:
  c:
    foreach: [unit, hour]
    expression: x <= shift(x, over=hour, offset=-lead, edge='wrap')

load:    OK
typeset: AssertionError            # bare, from _amount() in walk.py

_amount asserts isinstance(node.operand, NumberNode) after matching a UnaryOperatorNode, so a negated parameter trips the assert. Two things wrong: the language rule isn't enforced, and the failure is an assertion rather than a LanguageError with a sentence.

This is also load-bearing for #56/#59: the reason sum_forward must exist as an operator rather than a composition is that offset=-(p-1) is refused. Right now it isn't refused, it just breaks later.

2. An offset must vary only over dims the shift can read it at

it varies only over dims the shift can read it at — the shifted expression's own, or the one a by= lookup groups into. An offset is read at the coordinate it moves, and a dimension that coordinate does not have is no coordinate at all

Unenforced: a parameter over a dimension unrelated to the operand loads clean.

3. A named offset requires an edge=

it says what the vacated positions contribute — edge='wrap' or a number. The bare form's absence is carried by a frame keyed by the translated dimension alone, and a per-entity offset vacates a different slot for each entity, which that frame cannot yet say.

Unenforced: shift(x, over=hour, offset=lead) with no edge= loads clean.

What it should be

All three as load errors in the language's own wording. (1) should also stop being an assertion — _amount's precondition becomes true only once the rule is enforced, so the check and the assert belong in the same change.

_check_named_amount in dimensions.py (added by #61) is the natural home for (2); (1) and (3) are call-shape facts and may fit resolution.py better, where arity is already checked.

Version

v0.0.0-alpha.10

[FBumann]

Split. Two of the three are fixed in #63:

• a negated named amount is refused at load, so shift(offset=-lead) gives a sentence instead of a bare AssertionError out of the typesetter;
• an amount is refused where the coordinate its operator walks carries no dim to read it at — with by= admitting the dims a partition maps into, so a per-group lag or width stays legal.

The third — a named offset requires an edge= — is #64. Its justification is a downstream frame limitation that the docs hedge ("cannot yet say"), so enforcing it would bake one consuming lane's current capability into a package that is deliberately lane-independent. That is a design call rather than a bug, and wants deciding on its own.

[FBumann]

Two of the three are fixed on main by #63, verified there:

• shift(offset=-lead) is refused at load with a sentence, where it used to load clean and raise a bare AssertionError out of the typesetter. That was the rule walk.py reads a named offset as always-backward because of, so it is enforced now rather than assumed.
• An amount declared over a dim the walked coordinate does not carry is refused, and a by= still rescues it — one lag or width per group.

The third — a named offset requires an edge= — is #64 and stays open. It is a design decision rather than a bug: its justification is a downstream frame limitation the docs hedge ("cannot yet say"), so enforcing it would put one consuming lane's current capability into a package that is deliberately lane-independent.

Closing this in favour of #64.