Relationships

Stable — Stable features are ones that have earned their place in the core prose language.

universe ClockworkVillage {
  describe { ... }
}

dimension place { describe { ... } }
dimension thing { describe { ... } }

relationship isNextTo { describe { ... } }
relationship sitsOn and isSatOnBy { describe { ... } }

concept Villager {
  describe { ... }

  relationships {
    sitsOn { Bench }
  }
}

place Well {
  describe { ... }

  thing WellRope {
    describe { ... }
  }
}

place Pond {
  describe { ... }
}

place Bench {
  describe { ... }

  relationships {
    isNextTo { Pond }
  }
}

What it is

The connections a thing actually has. A relationship names a word; a relationships block spends it.

The village finally has edges. A villager sits on the bench, and the bench is next to the pond. Nothing was renamed and nothing moved to make room for them.

You only ever declare one side. sitsOn { Bench } on Villager is enough — the bench is sat on by the villager without anyone writing it down, because the relationship already named both words. Write the other side as well only when that end has something of its own to say about the connection, which is what an edge block is for.

Each edge, separately

Experimental. A connection can carry a sentence of its own. Follow the target with a block, and put a describe in it.

universe ClockworkVillage { }

dimension place { }

relationship sitsOn and isSatOnBy { }

concept Villager {
  relationships {
    sitsOn {
      Bench {
        describe {
          Mostly in the evening, to watch the light go off the pond.
        }
      }
    }
  }
}

place Bench {
  relationships {
    isSatOnBy {
      Villager {
        describe {
          Worn smooth at the end nearest the water.
        }
      }
    }
  }
}

That is one connection, written from both ends, and each end says something different about it. The villager's sentence is about why it sits there; the bench's is about what the sitting has done to it. The two are not expected to agree, and the language does not compare them.

A note stays where it was written. The other end still has the connection, but not the sentence, so where a note sits records who wrote it. Where it is shown is up to whatever reads the manifest.

An edge block holds a describe and nothing else. An empty one, or an empty describe, adds nothing to the connection. A relationships block inside one is refused for now, because it would make the connection something other connections can point at, and that is a larger step than a sentence.

Where it can live

Inside any concept or dimension. One block per scope, holding as many connections as it needs.

A dimension may carry its own relationships block. Those are facts about the kind itself, not about each of its members.

An edge block goes right after its target, in any relationships block: on a concept, a dimension, a pairing, or a relationship's pair or side. It belongs to that one connection, and to nothing else.

How names find it

Each word inside the block has to be a relationship in reach, and each target has to be a name in reach. A bare name is enough for a sibling or an enclosing concept. Anything else takes a path, including something nested inside the concept doing the naming.

A target may be a concept or a dimension, and the two say different things. isNextTo { Pond } is a fact about one pond. isNextTo { place } would be a fact about the kind — about places in general, not about every place individually.

A block names each target once under a word. Names are compared on what they resolve to, so Pond and ClockworkVillage.Pond under one word are the same target written twice, and the second is refused.

Nothing inside an edge block resolves. Its describe is text, like every other describe.

How it breaks

• SP004 DuplicateRelationshipsError — A scope may have only one relationships block.
• SP007 TargetNotFoundError — A name used as a target could not be found.
• SP015 RelationshipNotFoundError — That relationship word is not in reach.
• SP030 DuplicateTargetError — A relationships block names the same target twice under one word.

Decided in

• ADR002 NestedNameResolution — Nested name resolution. Accepted.
• ADR003 EndpointDimensionPairs — Endpoint dimension relationship pairs. Accepted.
• ADR006 DimensionsInRelationships — Dimension relationship endpoints. Accepted.
• ADR011 ExpectsBlock — Expects block. Proposed.
• ADR023 ErrorNameCorrections — Error name corrections. Accepted.
• ADR029 EdgeBlocks — Edge blocks. Accepted.
• ADR030 DescribeInEdgeBlocks — Describe in edge blocks. Proposed.