Loft grammar cheat-sheet (v0.4)

One statement per line. # starts a comment — comments are kept (they ride the statement below them, or the line they end, and survive reformatting). Blank lines are ignored. Type declarations may also take the block form: end the head with : and put one parameter per indented line beneath it (any consistent indent). Same model either way — the one-line form stays legal, and the formatter picks. Statement order across the file never matters — references resolve across the whole file. Within a line, slot order is fixed: category → type → [id] → placement (see Line anatomy). A model may span multiple .loft files: every file in a project directory compiles as ONE model with ONE namespace — reference names across files directly, with no import lines, and file layout never changes meaning (folders navigate, never scope).

Start here — build in this order

Everything below this section is reference. This section is method. Most broken models are correctly-spelled statements written in the wrong order and measured from the wrong thing.

# 1. datums first — the framework everything else is measured from
level L1 elev 0' height 10'-0"
grid A vertical   at 0'
grid B vertical   at grid.A + 24'-0"    # the bay width, not grid B's coordinate
grid C vertical   at grid.B + 30'-0"
grid 1 horizontal at 0'
grid 2 horizontal at grid.1 + 20'-0"

# 2. then hosts — walls today (floors and roofs later); frame first, then the line
# traveling (grid.A,grid.1) -> (grid.C,grid.1), heading east; right = south
wall EXT-1 W1 from (grid.A, grid.1) to (grid.C, grid.1) justify left

# 3. then what they host — a typed product, placed along the host off a datum
door 3070 D1 in wall.W1 at 4' past grid.B   # the 3070 doortype states the size once, below

# 4. then the views — what to draw, at what scale, cut where (a query, never a
#    container). A view owns its file: each goes in its own views/ file.
view plan L1-plan of level.L1 scale 1/4" cut 4'-0" name "Level 1 Floor Plan"

Datums first. Declare levels and grids before anything measured from them. Order doesn’t matter to the parser, but it matters to you: an element you can’t anchor is a datum you haven’t declared yet
Types declare facts once; instances reference a type and add only what it delegates. A door’s size is a fact about the product — state it in a doortype, and every placement follows. One rule, every category
Then hosts, then what they host. Walls carry doors and windows (floors and roofs will carry their own). An opening names its host and a station along it, so the host must exist as a decision before the opening can be placed — this is the order the model depends in, whatever order you type
Relative by default; absolute is the last resort. Prefer, in this order: a declared datum ((grid.A, grid.1)) → an expression off one (grid.A + 14') → another element’s datum (wall.W1.end, door.D1.jamb.far) → a bare literal. A literal is the right answer only where the number has no reference — an origin, or a free choice
Say the measurement, not the coordinate. grid C vertical at grid.B + 30'-0" states a bay width; at 54'-0" states a position and discards why it sits there. Widen the first bay and grid C follows on its own — the coordinate form leaves every later number to be recomputed by hand
One travel frame governs everything. A wall’s own from → to direction decides its left from its right — which face justify names, which way layers stack, which side swing hinges on, and where at 0' starts for its openings. Choose the direction, state it in a comment, then write the line
When travel and measurement disagree, anchor to a datum. Closing a perimeter often forces a wall to run opposite the direction you’d naturally measure along it. Rather than counting backwards from that wall’s start, place its openings off a grid: at 4' past grid.2
Check your work with the plan’s dims button — it cycles stated → measured → off. stated draws only the facts your statements assert: a grid dimensioned from the anchor you chained it off, a carrier’s offset, an opening’s position. measured draws the adjacent-pair chain a paper drawing would show, from resolved positions. If the stated view comes up nearly empty, you dimensioned in coordinates — there are no relationships in the model for it to draw

Line anatomy — how a declaration reads

Every declaration is category → type → [id] → placement, with a slot dropped where the category doesn’t carry it. One of the two leading name slots is always required, so the first name after the keyword is never ambiguous.

# element: the type leads and is REQUIRED; the id follows, optional
wall EXT-1 W1 from (grid.A, grid.1) to (grid.C, grid.1) justify left
wall STUD4 from grid.1 to grid.2 along grid.A   # anonymous — id omitted, type still leads

# datum: no type — the REQUIRED id leads (a datum exists to be referenced)
level L1 elev 0' height 10'-0"
grid A vertical   at 0'

# door/window: the type leads here too (and is required); the id follows, optional
door 3070 D1 in wall.W1 at 4' past grid.B   # the 3070 doortype states the size once, below

# opening: the type-less cutter — a hole has no product identity, so its
# dimensions live on the line; id optional, like walls
opening O1 in wall.W1 at 14' width 3' height 3' sill 4'

Read the element form as a noun phrase: wall EXT-1 W1 = “an EXT-1 wall, called W1” — the type says what it’s made of, the id names it, the rest places it
Declare an element id only when something will reference it — host an opening, anchor a chain (wall.W1.end), take a carrier offset. Datums always carry their id
The v0.1 trailing spelling (wall W1 from … type EXT-1) is retired — the parser recognizes it and answers with the corrected line

Lengths

Always carry units. Bare numbers are never lengths.

12'   8"   12'-6"   12'-6 1/2"   27.5'   4.5"   5/8"   3-5/8"   12ft   8in

Word suffixes (12ft, 8in) are accepted on input; canonical output prints the symbol forms
Rejected near-misses: 12'6" (the hyphen is mandatory — write 12’-6”) · 1/2' (no fractional feet — write 6”) · 12 (bare numbers are never lengths — write 12’)

Coordinates

(x, y), plan view: positive X is right (east), positive Y is up the page (north). Each slot is a length literal or a position expression over datums:

(12', 28')     (grid.A, grid.1)     (grid.A + 14', grid.1)
(grid.B - 4', grid.2)     (grid.A + (grid.B - grid.A)/2, grid.1)

A bare token is never a reference and a bare number is never a length: a reference names its category (grid.A), a length carries its units.

Expressions

Anywhere a position or distance goes, a static expression works: + - * /, parentheses, datum references.

grid A5  vertical at grid.A + (grid.B - grid.A)/2 label "A.5"  # midpoint between grids A and B
grid D   vertical at grid.C + 12'                              # chained off C
door 3070 D4 in wall.W1 at (grid.2 - grid.1)/2                 # centered: half the 1-to-2 span

Declared vs projected: grids and levels are declared datums — they get their own statements; elements project the rest (wall.W1.end, door.D1.hinge). Both are named datums. An expression like grid.A - 5' is a position, not a datum — nothing can reference it later; where a slot demands a named datum, declare one there: grid A1 vertical at grid.A - 5' label "A.1"
A datum reference is a position; two same-axis positions subtract into a distance; positions never add, multiply, or divide
Bare numbers only multiply or divide — a bare number is never a length
An offset needs an anchor: write grid.A + (grid.B - grid.A)/2, not (grid.B - grid.A)/2
Space the minus between names: (grid.B - grid.A)/2, never (grid.B-grid.A)/2 — hyphens are name characters (as in EXT-1)
Cycles between datum positions are errors
Every reference names its category — grid.2, level.L1, wall.W1.end — so a name is never ambiguous and never guessed

Project & units

project "Sample Project"      # optional
units imperial                # optional; imperial is the v0 default

Levels

A level has three facts: elev; above — the level above it, worked out from the elevations when you don’t write it, written (above level.L3, or above none) when the next level up by elevation isn’t the one; and height, worked out from above when you don’t write it (the topmost level repeats the story below). Story height is a fact about the building, stated once. A level has above; an element has top; top above is how they meet.

level L1 elev 0' height 10'-0"
level L2 elev 10'-0"                # story worked out: L3's elev minus L2's
level L3 elev 21'-0" height 9'-0"   # the top level states its story (else it repeats L2's)
level L1                            # this FILE's level — the default base for its elements

above <level> names the level above when the default is wrong — a mezzanine you don’t want to stop at; above none says nothing is above; height beside either overrides the worked-out story. A level has no top (write above); stack is reserved
A level is declared once in the unit (any file, any position — datums beside the grids by convention). A bare level L2 line is the file’s level statement: file-scoped content that sets the default base for every element in the file that has one. A default, never a requirement — at most one per file, legal anywhere in it
With exactly ONE level declared, it is every element’s default and no file statement is needed. With two or more, an element needing a base must get one — from the file’s statement, or its own base — or the error on the element names both fixes
Elements default to their level’s base and top: a wall runs from its level to that level’s top (its elevation plus its story); base level.L2 + 7', height 9', top level.L3, and top above — the file’s next level up — override per instance (see Walls)

Grids

grid A vertical   at 0'
grid 3 horizontal at 28'-0"
grid B5 vertical  at grid.B + 12'-6" label "B.5"

vertical = line of constant X
horizontal = line of constant Y
An id carries no dot — declare grid A5 … label "A.5" and the bubble reads A.5 while every reference says grid.A5

Wall types

walltype STUD4 width 4.5" note "3-5/8 stud + gyp ea side"
walltype EXT-1 layers [brick 4", air 1", core: stud 6", gyp 5/8"]

Layers stack left → right of the wall’s travel (flip mirrors them)
core: marks the structural layer

Door & window types

The category requires; the type binds. Every door/window type must satisfy width and height — by fixing a value (stated once, every placement follows) or delegating it (the word instance: each placement supplies it).

doortype 3070 width 3'-0" height 7'-0"                # fixed: a product fact, stated once
doortype STOREFRONT width instance height 8'-0"       # width delegated to each placement
windowtype W-5040 width 5'-0" height 4'-0"
doortype HM-A:                                        # block form: one parameter per indented line
  width 3'-0"
  height 7'-0"
  u-fire-rating "90"                                  # minutes
  u-hardware instance text required

Rhymes with walltype: keyword, type name, parameter pairs. Type names are project-unique per category
Block form (doortype HM-A: + indented lines) and one-line form are the same declaration — the block reads better past two or three parameters, and each parameter line is its own error address. Only doortype/windowtype take a block in v0.4; walltype stays one-line
Supplying a fixed parameter on a placement is an error naming the type and its value — duplicate the type to change it. Omitting a delegated width/height is an error too: the placement owes what the type left open
u-<name> adds user parameters — job-specific data that rides the format (typed from the literal: length, true/false, or quoted text — a count or a rating is text, since no literal spells a bare number; a delegated one states its type: u-hardware instance text). One name has ONE value type within its category — u- vocabulary belongs to the component, so a windowtype may type the same name differently than a doortype
A delegated u- parameter is optional unless the type adds trailing required — then every placement must supply the pair, same error as a missing delegated width
swing, reverse, and sill stay on placements — per-placement facts, never product facts (a door’s unstated sill is the level; a window’s is required)

Walls

A wall’s line is stated one of two ways — by its endpoints, or by a carrier it rides plus two extents that cut it. Both are first-class; pick whichever states the facts you already know. Carrier + extents is not a partition trick — an exterior wall running along a grid is the case it fits best. It is how a line-based element is placed — walls and roomlines today, every line element to come.

# by endpoints
wall EXT-1 W1 from (grid.A, grid.1) to (grid.C, grid.1) justify left

# by carrier + extents — the carrier fixes the line, two transverse datums cut it
wall EXT-1 W2 from grid.1 to grid.2 along grid.A justify left   # ALONG grid A — no offset, no side
wall STUD4 W7 from grid.1 to grid.2 at 4' right of wall.W2      # 4' clear of W2's core face
wall STUD4 from grid.1 to wall.W5.end at 9' left of grid.B      # grid carrier; a wall's line datum cuts too

# vertical facts — base and top name levels; one wall may span stories
wall EXT-1 W9 from (grid.A, grid.3) to (grid.B, grid.3) base level.L1 top level.L3   # a shaft wall, L1 up to L3

Order is category, type, id, placement — wall EXT-1 W1 from … reads “an EXT-1 wall, called W1” (and rhymes with its walltype EXT-1 declaration)
id (W1) optional — required only to host doors/windows
justify: centerline (default) | left | right — which face of the wall the drawn line is, in YOUR from → to direction (you typed it; you already know left from right). A side may name its plane: bare left is the finish face; justify left foc holds the structural core face (fos/foc/fom — face of stud/concrete/masonry, one plane, three field spellings), justify left fof says finish face out loud; justify core.centerline holds the core’s own center (differs from centerline on an asymmetric assembly). Hold the core when finishes may change — it’s the plane that doesn’t move
Everything is in the travel frame: layers stack left → right, door arcs open right; flip mirrors that content, never the body
Draw perimeters clockwise with justify left and the outside faces out
Carrier — along <ref> rides the location line ALONG a declared reference plane and justify places the body; at <offset> <side> of <ref> holds it off one instead. A wall carrier always needs both a side and an offset (along wall.W3 is an error)
Extents — any two transverse datums: grids, crossing walls, or wall line datums (wall.W5.end)
left/right are the frame of the wall THIS statement declares — its own from → to travel — never the carrier’s
Derive the frame in a comment before picking a side — # traveling W4→W5 (east), right = south — and the side words stop biting
A wall carrier with no plane named measures from the wall’s core face on your side — at 4' right of wall.W3 is 4’ clear of W3’s studs/block, same rule as past wall.W3; name another plane to measure elsewhere (right of wall.W3.fof the finish, right of wall.W3.centerline the center). Extents (from wall.W1 to wall.W3) are joins — the wall runs to the crossing wall’s centerline. The wall must sit clearly on the stated side (zero or straddling offsets are errors)
State each fact once: edit the offset and the wall, its openings, and its dimensions all move together
Vertical facts: a wall’s base is its level (the file’s level statement, or the unit’s one level) and its top is that level’s top. base <level> [± offset] pins the base per instance (Revit’s Base Constraint + Base Offset) — a wall from L1 to L4 is one element, and base level.L1 top level.L4 says where it lives. height 9' and top <level.L3|wall.W1.top> [± offset] override the top as ever (height defaults to the rest of the base level’s story)

Element datums (anchors & accessors)

Every element projects datums you can reference — <category>.<id>.<datum> (wall.W1.end, door.D1.jamb).

wall EXT-1 W4 from wall.W1.end to (grid.C, grid.2)    # chain: W4 follows W1
wall STUD4 W5 from (grid.A + 12', grid.1) to (grid.A + 12', grid.2) top wall.W1.top
door 3070 D5 in wall.W1 at 6' past door.D1.jamb   # measured from D1's jamb, not its center

Projection table — wall: start · end · centerline · core.centerline · fos/foc/fom · fof · top · base | door: centerline · head · jamb · sill + hinge/strike (swinging leaf) | window: centerline · head · jamb · sill | opening: centerline · head · jamb · sill (the base interface, nothing more)
Line datums (wall.W1.end) fill a whole coordinate slot; plane datums (wall.W1.centerline, wall.W1.core.centerline, wall.W1.top) join expressions on their axis; opening datums are stations — reference them in directed measurements (past door.D1.jamb)
Wall planes, field notation: fos / foc / fom = the structural core face (face of stud / concrete / masonry unit — ONE plane; spell it for the material), fof = finish face, cl = centerline anywhere it appears (wall.W6.cl, door.D1.cl, to cl), core.centerline = the core’s center. Faces come in pairs, so they resolve where a tape can pick the side: at 4' past wall.W6.foc measures from the core face facing the opening (past wall.W6, with no plane named, means the same); in an expression, use .centerline / .core.centerline. ff is held for far face — finish face is fof
jamb.near/jamb.far are framed by the host wall — near toward its start, far toward its end (the origin at measures from). Stable in any direction, so at 2' past door.D1.jamb.far reads as it sounds
Bare jamb is whichever jamb the measurement reaches first — the one nearer the reference you measured from. Swap past for short of and it changes ends, which is why bare jamb always needs a direction word
Opening datums are stations (lengths from the wall’s start), so they do arithmetic in that wall’s own at: door 3070 D9 in wall.W1 at door.D1.jamb.far + 2'
Flip the swing and the jambs don’t move; rehang the door and hinge follows
Guardrail: anchor to declared datums (grids, levels) by default, to elements by exception — chains state genuinely relative intent, never a substitute for gridding
Driver → driven, one direction: W2 follows W1, W1 never feels W2; cycles are errors

Doors

door 3070 D1 in wall.W1 at 4' past grid.B   # the 3070 doortype states the size once, below
door 3070 D2 in wall.W5 at 2' past grid.1 swing left
door 3070 D3 in wall.W5 at 3' short of grid.2
door STOREFRONT D6 in wall.W1 at 20' width 6'-8"   # STOREFRONT delegates width; the placement supplies it

The size lives on the doortype, not the line (see Door & window types) — a parameter pair is legal on a placement only when the type delegates that parameter
at measures from the wall’s start to the door center — a plain length is a station from that start (at 4'-0"), and everything below measures the same station off a datum instead
past <ref> measures forward from a reference; short of <ref> holds back from one — both along the wall’s from→to travel. A grid line or a datum like door.D1.jamb.far is a POINT: the tape runs from it to this opening’s center. An ELEMENT reference with no datum named (past door.D4) measures clear — from the reference’s facing jamb to this opening’s facing jamb — so at 0' past door.D4 is a flush sidelite, and past door.D4.centerline is the center-to-center spelling. A CROSSING WALL with no plane named (past wall.W6) is its core face facing this opening — face of stud/concrete/masonry, the plane a finish change never moves — the same as past wall.W6.foc; name another plane to measure elsewhere: past wall.W6.centerline (or .cl, the wall’s center), past wall.W6.fof (finish face), past wall.W6.core.centerline. From a wall the landing stays this opening’s center; add to jamb for clear
Add to jamb to measure to the opening’s near jamb instead of its center — the jamb the measurement reaches first, coming from the reference: at 2' past grid.1 to jamb. to jamb.far measures across to the far side instead (“the opening ends at 10’”): at 10' to jamb.far. (to edge, the older spelling, still parses; with an element reference, the near jamb is already the default landing.) to centerline overrides the other way — the measurement lands on the opening’s center: at 4' past door.D4 to centerline puts D4’s far jamb 4’ from this door’s centerline
swing is the hinge side (wall’s travel frame); doors open away from the wall’s facing — add reverse to open toward it. Hardware handing verbatim: swing left = LH, swing left reverse = LHR
Defaults: swing right; height and width come from the type, always

Windows

window W-5040 WIN1 in wall.W2 at 6'-0" sill 3'-0"
window W-5040 WIN2 in wall.W2 at 4' past window.WIN1 sill 3'-0"   # 4' clear of WIN1's jamb

Same binding rule as doors: size on the windowtype, placement facts on the line
sill is required on every window and has no default — a sill height is where THIS window sits, not what the product is, so the type can’t supply it
It measures up from the level, not from the wall’s base: two windows written sill 3'-0" sit at the same elevation even when one host wall starts lower. sill 0' is a legal answer

Openings

opening O1 in wall.W1 at 14' width 3' height 3' sill 4'

The type-less cutter: a hole has no product identity, so instance dimensions are correct here — not a workaround. width and height are both required (no type carries them); an unstated sill is the level itself — a floor-to-head passage
sill measures up from the level, exactly as a window’s does — a hole and a window sit on the same plane
Same placement grammar as doors/windows (past / short of / to jamb / to centerline), and it projects the base datums (opening.O1.jamb.far)

Rooms

room 210 name "OFFICE" at (7', 14')   # number (the id — any text: 210, 210A, A-101), name, point; boundary and area are derived
roomline from (grid.C, grid.2) to (grid.C, grid.3)   # closes a boundary where no wall does — an open-plan split
roomline RL1 from wall.W1 to grid.2 at 12' right of grid.A   # positions like a wall: carrier + extents, or a point pair

A room point marks an enclosure — anchor it to declared datums only (grid expressions fine: at (grid.A + 12', grid.1 + 8')). Element datums (wall.W1.end) are errors here: a wall edit must never drag a room along. The id is the room NUMBER — unique, optional, any id text (210, 210A, A-101, 210-1; a hyphen inside a token is always part of a name, so subtraction is always spaced: grid.2 - grid.1) — and it is what doors and finishes will reference; name is the tag text
The boundary is derived from the walls around the point (finish faces; doorways don’t break it) and the area shows on the plan tag and the takeoff. A room whose walls don’t close reads NOT ENCLOSED and the plan rings the open ends — close the wall, extend it, or draw a roomline; two room points in one enclosure each report the other
roomline is a zero-width room separation line: no type, no geometry, no 3D — a hairline on the plan. It uses the same placement as a wall (point pair, or from <extent> to <extent> at <offset> left|right of <ref> / along <grid>), may reference grids and walls, and nothing references it — it only closes a boundary. Id optional

Views

A view is a declared query over the model — never a container of elements. Every fact a view has is authorable on the view line itself; a viewtype is an OPTIONAL template — a named bundle of defaults — and a written fact on the view is a visible override. A view owns its file: each view statement lives in its own views/ file (its page), with only project, units, and viewtype declarations allowed beside it.

# untyped: kind → id → the level it is "of" → [crop] → [facts] → [name]
view plan L1-plan of level.L1 scale 1/4" cut 4'-0" name "Level 1 Floor Plan"
view plan L1-min of level.L1               # every fact optional — scale defaults to 1/8", cut to 4'-0"
# or through a template: shared defaults, per-fact; the instance's own words win
viewtype plan A-PLAN scale 1/4" cut 4'-0" depth -10'-0"   # the view range: looks one story down
view A-PLAN L1-key of level.L1 scale 1/8"  # 1/8" here overrides the template's 1/4"
# the crop: lower-left corner to upper-right — what the view shows; corners are ordinary coordinates
view A-PLAN L1-kitchen of level.L1 from (grid.A - 5', grid.1 - 5') to (grid.C + 5', grid.2 + 5') name "Kitchen — Enlarged Plan"
# a section: "at" the cut plane, "to" the far clip — stations on one axis; the gaze is their sign
view section S1 at grid.1 + 4' to grid.3 name "Building Section"
view elevation E1 at grid.1 - 10' to grid.3 top level.L3 + 2' bottom level.L1   # trims anchor to LEVELS
view section S2 horizontal at 10' to 40'   # no grid named — the axis word says which way the plane runs

One view per file. A file holding a view holds only that view — a second view, or any element beside one (a wall, a room, even a walltype), is an error teaching the split. viewtype is the exception: a type declaration lives anywhere, so a template may sit beside the one view that applies it, or with the other types. Declaring a view is the moment a project becomes a directory; a single file with no view still draws — the implicit plan of its level, at the 1/8” default
Slot order is every statement’s: category → type-or-kind → id → placement. The second word is a viewtype reference or a bare kind word (plan, section, elevation) for an untyped view; kind words can never name a viewtype. The id is what references the view (a token); name "…" is the title that prints and what the picker shows — optional, trailing everything. The placement is the kind’s own: a plan is of a level (neither hosted in nor placed at; of level.L9 with no such level is an unknown-datum error naming the levels you do have), a section or elevation is placed by its plane: at <station> to <station>
The kinds are plan, section, elevation; rcp is a reserved word that names its era; a discipline (structural, MEP) is a filter on the query, never a kind
Sections and elevations are one machine under two words — the drawing set’s vocabulary. at is the cut plane’s station, to the far clip’s, each an ordinary station expression (grid refs preserved, wall anchors refused — a wall edit must not move the drawing); the view looks from at toward to and sees that far, so swapping them looks the other way, and to equal to at sees nothing. The axis comes from the grids the stations name; name none and the axis word leads: vertical/horizontal before at. Walls the plane crosses draw CUT — paper mass bounded by the cut pen, no poché (cut beside a wall, not on it: a plane down a wall’s own line cuts it at full length); walls beyond draw in the projection pen, nearer covering farther, openings punched from cut walls and projected on beyond faces; the mass’s outline profiles at the cut pen (the drawing is read by its silhouette); every level draws as a datum line with its name and elevation. Optional top/bottom trim the frame at LEVELS (top level.L3 + 2' — a bare length is a plan’s range word, not a trim); untrimmed shows everything, ground to bulkhead
The facts — scale, cut, and the range words top/bottom/depth — are each optional on both statements, any authoring order (canonical print order: scale cut top bottom depth). Resolution is per fact: the instance’s word, else its viewtype’s, else the language default — scale 1/8” flat, cut 4’-0”. Scale is a length literal in paper inches per model foot (1/4", 1/8", 3/16", 1"); it sizes the hatches, the text, and the line weights, so zooming the plan magnifies the drawing instead of changing its scale. Cut is a length above the level
The view range — top, bottom, depth — are lengths relative to the level (a leading - reads below it). Defaults when unwritten: top = the level’s top, bottom = the level, depth = bottom. What a plan shows is computed against them, never authored: an element crossing the cut plane draws cut; wholly between the cut and the top, dashed (above); wholly below the cut and above the depth, in the projection pen (beyond — depth -10' is how a plan shows the story below); outside the range, not at all. Openings follow their host. The relationships are errors with the fix written out — bottom above the cut, top below it, depth above bottom — checked over the effective values, so an authored word conflicts even with a defaulted one
from (x, y) to (x, y) after the query is the crop — the rectangle the view shows (Revit’s crop region), from the lower-left corner, to the upper-right. It is a placement on the view, before the facts; the corners are ordinary coordinates, so a crop to grids follows them when a bay widens, and a corner off an unknown grid is the usual unknown-datum error. Anchor corners to grids or literals, never to a wall (from wall.W1.end is refused like a room’s point). An inside-out pair (to left of or below from) is an error with the swap written out, never silently fixed. Grid lines end on the crop, bubbles sit just past it, dimension strings stack just inside it (paper offsets from the standard, the same at every scale), and elements outside it clip — a grid the crop doesn’t reach, a string to it, a string or room tag not wholly inside it, are hidden, never half-drawn. No crop: the view shows the whole model plus a margin
A view takes no indented body — annotations (dimensions, tags, notes) are reserved for a future version. New projects start two files — model.loft and the plan’s own views/ file — no project ships with zero views

Reserved keywords

Every major building category is reserved for future versions — using one is an error (not silently ignored). Highlights:

component  import  export  const  refplane  detail  sheet  schedule
floor  roof  ceiling  stair  ramp  railing  column  beam  shaft
curtainwall  duct  pipe  conduit  furniture  site  topo  zone  space
floortype  rooftype  materialtype  hatchtype  layertype  …

instance is a reserved value word: the delegation marker inside type declarations, an error as a value anywhere else

Words per statement

Every word each statement takes, from the category catalog — the same rows the parser reads. The type slot is type; a word’s options follow it; a default sits in parentheses; the words reserved for a future version come last, with what will read them.

project — no words
units — no words
level — elev · above <level>|none (the next level up by elevation) · height (the story to above; the topmost level borrows the story below) · reserved: stack (a real interleaved-sequence model (a garage’s 8’ levels beside the podium’s 10’ ones)); label (a bubble or tag printing text other than the id — the grid’s bubble is the one that ships)
grid — vertical|horizontal · at · label
walltype — width · layers · note
doortype — width · height · u-<name> · reserved: fire-rating (the duration value type (90 min, 2 hr) — every parameter value carries units; until then the corpus spells it as text, u-fire-rating "90"); hardware-set (the door worksheet — u- today, a built-in candidate then); kind (a second kind of leaf — the door’s and the window’s declarations list what is coming (D0242))
windowtype — width · height · u-<name> · reserved: fire-rating (the duration value type (90 min, 2 hr) — every parameter value carries units; until then the corpus spells it as text, u-fire-rating "90"); hardware-set (the door worksheet — u- today, a built-in candidate then); kind (a second kind of leaf — the door’s and the window’s declarations list what is coming (D0242))
wall — type · from · to · along · left · right · justify centerline|left|right|core.centerline (centerline) · flip (off) · base (the file’s level) · top (the wall’s level’s top) · height · reserved: function (the wall worksheet’s second pass — decided at decision 65(e), not yet a clause); structural-usage (the structure era); room-bounding (the furred or decorative wall that must not bound a room; bounding is per story since decision 74); label (a bubble or tag printing text other than the id — the grid’s bubble is the one that ships); phase, demolished (the phasing era — phases are an ordered list declared in their own file, and a view looks at the model as of one)
door — type · in · at · past · short · width · height · u-<name> · sill (the host level + 0’) · swing left|right (right) · reverse (off) · reserved: label (a bubble or tag printing text other than the id — the grid’s bubble is the one that ships); phase, demolished (the phasing era — phases are an ordered list declared in their own file, and a view looks at the model as of one)
window — type · in · at · past · short · width · height · u-<name> · sill · reserved: label (a bubble or tag printing text other than the id — the grid’s bubble is the one that ships); phase, demolished (the phasing era — phases are an ordered list declared in their own file, and a view looks at the model as of one)
opening — in · at · past · short · width · height · sill (the host level + 0’) · reserved: label (a bubble or tag printing text other than the id — the grid’s bubble is the one that ships); phase, demolished (the phasing era — phases are an ordered list declared in their own file, and a view looks at the model as of one)
room — at · reserved: level (a room that differs from its file’s level); department, occupancy (roomtype, or u- on categories); phase, demolished (the phasing era — phases are an ordered list declared in their own file, and a view looks at the model as of one)
roomline — from · to · along · left · right · reserved: phase, demolished (the phasing era — phases are an ordered list declared in their own file, and a view looks at the model as of one)
viewtype plan — scale (1/8”) · cut (4’-0”) · top (the level’s top) · bottom (the level + 0’) · depth (the range bottom) · reserved: units (the metric / areas era — a tier on the view ?? viewtype ?? project cascade)
viewtype section|elevation — scale (1/8”) · reserved: units (the metric / areas era — a tier on the view ?? viewtype ?? project cascade)
view plan — type · of · from · scale (1/8”) · cut (4’-0”) · top (the level’s top) · bottom (the level + 0’) · depth (the range bottom) · name · reserved: phase (the phasing era — the phase filter, discipline’s twin (a filter on the query, never a kind)); discipline (the views/filters era — phase’s twin (a filter on the query, never a kind); object styles stay one standard, the view’s discipline picks the resolver cell the way its scale does)
view section|elevation — type · vertical|horizontal · at · to · scale (1/8”) · top · bottom · name · reserved: phase (the phasing era — the phase filter, discipline’s twin (a filter on the query, never a kind)); discipline (the views/filters era — phase’s twin (a filter on the query, never a kind); object styles stay one standard, the view’s discipline picks the resolver cell the way its scale does)

Start here

Categories

Reference

Examples

Loft grammar cheat-sheet (v0.4)

Start here — build in this order

Line anatomy — how a declaration reads

Lengths

Coordinates

Expressions

Project & units

Levels

Grids

Wall types

Door & window types

Walls

Element datums (anchors & accessors)

Doors

Windows

Openings

Rooms

Views

Reserved keywords

Words per statement

​Start here — build in this order

​Line anatomy — how a declaration reads

​Lengths

​Coordinates

​Expressions

​Project & units

​Levels

​Grids

​Wall types

​Door & window types

​Walls

​Element datums (anchors & accessors)

​Doors

​Windows

​Openings

​Rooms

​Views

​Reserved keywords

​Words per statement

Start here — build in this order

Line anatomy — how a declaration reads

Lengths

Coordinates

Expressions

Project & units

Levels

Grids

Wall types

Door & window types

Walls

Element datums (anchors & accessors)

Doors

Windows

Openings

Rooms

Views

Reserved keywords

Words per statement