Skip to content

An example name asserted outside the format it exemplifies pins nothing (Nguyen Thi Van is pinned under FAMILY_FIRST) #470

Description

@derek73

rules.md#P6 pins Nguyen Thi Van under both family-first orders:

"Nguyen Thi Van"  family-first-given-last  →  given="Van"
"Nguyen Thi Van"  family-first             →  middle="Van"

It is an FFGL-format name. Its FF reading is wrong by construction, so the second line asserts an output nobody wants and nothing should depend on — and freezes a value that a future fix would have to be described as "breaking". The same shape, reversed, applies to Beethoven Ludwig van asserted under FFGL.

An example name carries a format. Asserting it outside that format tests the parser against a premise the name never had.

rules.md has nowhere to record this today: an example line carries an input, an optional policy annotation, a field and a value, but nothing that says which format the name is written in — so there is no way to distinguish "this is the answer for this name" from "this is what falls out if you parse it under a format it was never written in".

Why this bites now, measured

rules.md's ambiguous-particle coverage is one word deep. Of the 37 ambiguous particles in the shipped vocabulary, only 4 appear in an example where the particle stands alone: abu, del, do, van — and van is 12 of those 18 occurrences. von, le, la and freiherr appear only inside chains (Freiherr von Berg, de la Vega).

So a rule about a lone ambiguous particle is effectively tested through one word, and that word drags a second particle (van der) behind it. A format label would make it visible that the coverage is one name deep rather than eight.

Questions

  • Should an example line be able to declare its format, and should the doc test refuse to run a name outside it?
  • Or is the right unit a Not-an-example-of: note, so the FF line for Nguyen Thi Van can be deleted with a reason rather than silently?

Activity

  1. self-assigned this
    on Aug 30, 2026
  2. added this to the v2.3 milestone on Aug 30, 2026
  3. derek73 commented on Sep 2, 2026

    @derek73
    OwnerAuthor

    Closing: no notation is needed. The Accepted: clause is already the
    right home for this, and both halves of the issue turn out not to hold.

    Measured against master at c1a98a9, 2026-09-02.

    The example is stale in both halves. #467 deleted the FAMILY_FIRST
    line from P6 and left an Accepted: clause saying why. And the output
    this issue quoted is no longer what the parser produces:

    family-first               family='Van Nguyen'  given='Thi'  middle=''
    family-first-given-last    family='Nguyen'      given='Van'   middle='Thi'
    

    So the FF reading is not middle="Van" — it is P6's own particle
    attachment firing, folding Van into the family. That is the behavior
    P6's earlier Accepted: clause already documents, in as many words: the
    ASCII spelling collides with the tussenvoegsel reading and the name
    loses its given name. The out-of-format reading is a consequence of a
    documented rule, not an unrecorded premise, and "Nguyen, Thi Van" → family="Van Nguyen" is already asserted three clauses above.

    No live instance, and no recurrence. Across all 240 example inputs
    in rules.md, six are asserted under more than one order — Jong Anke de, Juan de la Vega, Ménil Christophe de, Sheik abdul salam, de Mesnil Jean, de la Cruz Juan Carlos. Every one is deliberate: each
    asserts a different field or a different value, showing how the reading
    changes with the order. None is the shape this issue describes. A
    format: declaration would need explicit opt-ins on all six to catch
    nothing, and not-an-example-of: would enforce a convention that has
    been violated once and was fixed. mechanisms.md#MAKE-WRONG-STATES-UNREPRESENTABLE
    is for a convention that keeps being violated however clearly it is
    written down; this is not that.

    The coverage half is already answered, and declined. The numbers
    have moved and the shape holds: of the 37 ambiguous particles in the
    shipped vocabulary, 4 stand alone in an example (van 26, abu 3, do
    3, del 1 — 33 occurrences, so van is 26 of 33, not the 12 of 18
    filed here), von/le/la/freiherr appear only inside chains, and
    29 of the 37 appear in no example at all. But that is per-entry
    coverage, which rules.md's Not-in-scope already declines: "what the
    tests owe is one exercise per behavioral fork rather than one per entry"
    (mechanisms.md#VOCABULARY-EXERCISES-FORKS). The lone-ambiguous-particle
    fork has 33 exercises. They are a van monoculture — a real fragility,
    since a change to that word's membership moves 26 examples at once — but
    the fork is exercised, and a row pins a fork, not a wordlist entry.

    Recompute: parse Nguyen Thi Van under both orders through
    Parser(policy=...) with the policies in tests/v2/rules_doc.py; for
    the other two, walk parse_rules_doc(RULES_DOC.read_text()) and group
    example inputs by order-bearing annotation, and intersect the example
    words against Lexicon.default().particles_ambiguous.

    P6's Accepted: clause keeps its (#470) citation — it points at where
    the question was raised, and this comment is the answer.

  4. added a commit that references this issue on Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

docsDocumentation fixes and updatesquestion

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions