What are possessive chains in TypeGlish 0.2.3?

A possessive now nests. Writing 'Sarah's manager's email is priya@acme.com' declares a chain of owners, one entity deep at each step, so the compiler knows that the email belongs to Sarah's manager, who belongs to Sarah. You reference the far end with a dotted pointer, @{sarah.manager.email}, and it inlines the value at compile.

How do I reference a nested property in a TypeGlish prompt?

With a dotted variable pointer: @{owner.field}, or deeper, @{owner.owner.field}. The bracket type is still {} for a variable, and each segment resolves against the object the previous one bound. A segment that resolves to nothing is a dangling pointer and a compile error, the same as any other undefined reference.

How do I name a multi-word thing so it binds as one object?

Wrap it in the name-literal sigil: %account manager% is one name token, so 'The %account manager% is Priya' binds a single object and '%account manager%'s inbox' gives it a property. A bare multi-word definite like 'the support team' does not bind silently: the checker raises the advisory prompt/multiword-definite and offers the %...% quick-fix, because it will not guess where the name ends.

Does upgrading to 0.2.3 change how my existing .tg files check?

The change is additive. 0.2.3 teaches the possessive to chain and lets a wrapped compound own a property; files that already used a single possessive keep working. Under the hood the compiler now reads nouns and prepositions from one generated catalog instead of five hand-maintained lists, which is invisible from a .tg file. Run npx typeglish check after upgrading to confirm.

← Tidelines/ReleasesJul 20, 2026

TypeGlish 0.2.3: possessives that chain

One genuine grammar feature this release, and it is the one English uses constantly: the possessive now nests. Write the owner's owner's field the way you would say it, and point at the far end with a dotted @{a.b.c}.

by TypeGlish team5 min read#releasestypeglish 0.2.3

Whose is whose.

TL;DR 0.2.3 teaches the possessive to chain: Sarah's manager's email is priya@acme.com declares a chain of owners, and @{sarah.manager.email} inlines the value at compile. Multi-word names bind as one entity when you wrap them (%account manager%), so a compound can own a property too. Underneath, the compiler's nouns and prepositions now come from one generated catalog instead of five hand-kept lists. Upgrade with npm i -D typeglish@latest.

0.2.2 taught the compiler that "the" names an object. 0.2.3 teaches it whose. The headline is small to describe and used in almost every real prompt: a possessive can now nest, so Sarah's manager's email is a chain the compiler follows one owner at a time, and multi-word names bind as single entities that can own properties of their own. Upgrade with npm i -D typeglish@latest, or run it with no install at all: npx typeglish@latest check **/*.tg. Here is what shipped.

§1The possessive chains now

A possessive already bound a property of its owner: Sarah's email is ... attaches email to sarah, not to a new standalone object. What 0.2.3 adds is depth. A possessive can sit on top of another possessive, and the compiler resolves the chain one owner at a time: Sarah's manager is an owner, and Sarah's manager's email is that owner's field. It is the way you already describe org charts, account hierarchies, and order records in a brief, now read as structure instead of flattened into prose.

The payoff is at the reference site. You point at the far end of the chain with a dotted variable pointer, and it inlines the resolved value into the prompt the model reads:

escalation.tg✓ compiles

Sarah is the account owner.
Sarah's manager is Priya.
Sarah's manager's email is priya@acme.com.

WHEN an escalation is needed THEN email @{sarah.manager.email}.

That compiles to "... WHEN an escalation is needed THEN email priya@acme.com." - the dotted pointer walked sarah to manager to email and inlined the value. The CI guard on this post re-proves it compiles clean against the real checker on every build. Each segment resolves against the object the one before it bound, so a typo like @{sarah.manger.email} is a dangling pointer and a compile error, the same as any other undefined reference.

This matters for the kind of prompt our readers actually write. A support or booking agent is full of possessed things - the customer's order, the order's status, the account's owner - and until now the second level had to be flattened into a fresh name or a comment. Now the ownership is in the type system, so a rename or a wrong field is caught rather than silently shipped.

§2Compounds bind as one entity

Chains are only useful if the things in them can have real names, and real names are often more than one word: "account manager", "billing team", "Pro plan". 0.2.3 lets a compound bind as a single object and then own properties like any other. Wrap the words in the name-literal sigil %...% so the compiler knows exactly where the name starts and ends, and the compound behaves as one entity, possessive and all:

routing.tg✓ compiles

The %account manager% is Priya.
The %account manager%'s inbox is escalations@acme.com.

WHEN a refund is over 500 dollars THEN forward the case to @{account manager.inbox}.

The first line binds account manager as one object; the second gives it an inbox; the pointer resolves the dotted path and the rule compiles to "... forward the case to escalations@acme.com." A compound that owns is just the chain from §1 with a multi-word owner.

The one rule to remember is that the wrap is not optional for a multi-word name. The compiler will not guess where a bare multi-word name ends, so it never binds one silently - it advises instead, and hands you the fix:

front-line.tgprompt/multiword-definite

The support team is the front line.

This does not block a compile - it is an advisory, prompt/multiword-definite - but nothing binds, so @{support team} would dangle. Wrap it as %support team% to declare one object. This is the same guardrail the "the"-object system shipped in 0.2.2, now doing double duty for compound owners; the guard on this post asserts the checker emits exactly that code.

§3Under the surface, and the smaller changes

The feature above rests on a quieter change. To read "manager" as an owner and "'s" as possession reliably, the checker needs to know its nouns and its prepositions - and until now those lived in five separate hand-maintained lists that could drift apart. 0.2.3 collapses them into one generated lexical plane: a single nouns catalog and a prepositions leaf, generated from the language's source of truth rather than typed by hand. You will not see it in a .tg file, but it is what makes the possessive chain read the same way every time, and it retires five places a mistake used to be able to hide.

A syntax-highlighting fix for mid-line pointers. In the editor, a Monarch tokenizer bug let a pointer's @ in the middle of a line escape into a comment, so the rest of the line rendered greyed out as if commented. 0.2.3 fixes the @-escaping so a mid-line @{...} highlights correctly and its tail stays live text.
Three new places to learn the language. The docs at typeglish.dev/docs gain a Concepts section with a language overview, a Best practices guide to the authoring workflow, and a Cookbook tab of runnable recipes. The guide and the recipes are CI-gated, so the examples in them are checked against the compiler the same way the ones in this post are.
The map of English. The roadmap now carries a closed coverage ledger - an honest accounting of which corners of English the checker reads today and which it does not - so the language's reach is legible instead of implied.

Field note

0.2.3 is a focused release: one grammar feature that English leans on constantly, the lexical refactor that makes it trustworthy, an editor highlighting fix, and more docs. There are no benchmark or adoption numbers to report, and the feature fires only what it can prove - a possessive chain resolves, a bare multi-word name advises rather than binds. The full changelog lives on GitHub. For the object system this builds on, read the 0.2.2 notes; to see possessed things in a real spec, the booking-agent walkthrough is the one to follow.

FAQQuestions about 0.2.3

What are possessive chains?: A possessive now nests. Sarah's manager's email is priya@acme.com declares a chain of owners, one entity deep at each step, so the compiler knows the email belongs to Sarah's manager, who belongs to Sarah. You reference the far end with a dotted pointer, @{sarah.manager.email}, and it inlines the value at compile.
How do I reference a nested property?: With a dotted variable pointer: @{owner.field}, or deeper, @{owner.owner.field}. The bracket type is still {} for a variable, and each segment resolves against the object the previous one bound. A segment that resolves to nothing is a dangling pointer and a compile error.
How do I name a multi-word thing so it binds?: Wrap it in the name-literal sigil: %account manager% is one name token, so The %account manager% is Priya binds a single object and %account manager%'s inbox gives it a property. A bare multi-word definite like "the support team" does not bind silently - the checker raises prompt/multiword-definite and offers the %...% quick-fix.
Does upgrading change how my existing files check?: The change is additive. 0.2.3 teaches the possessive to chain and lets a wrapped compound own a property; files that already used a single possessive keep working. The compiler also reads nouns and prepositions from one generated catalog now instead of five hand-kept lists, which is invisible from a .tg file. Run npx typeglish check after upgrading to confirm.

∿ washed up Jul 20, 2026 ∿