Specification · v1

Changelog

v1: ulang-lite 0.1.0

Released 15 October 2026 in ThinkTechHoldings/ulang-git at commit 61af4281ed, MIT licensed.

Number literals with an exponent (1e3, 2.5e-1) are floats. A single = after a name, path or boolean word parses as an assignment and is refused as unsupported[condition-form].

Errata

Known differences between ulang-lite 0.1.0 and the intent of this specification. Each one is checked when the site is built, so this list cannot go stale silently.

IssueEffectUntil fixed
E1A constant's source tag written with a space after [, as in [ SOURCE:P], is accepted, but its canonical text is [SOURCE:[ SOURCE:P]], which does not re-parse. Clause tags written this way are already refused (semantic[clause-id]).Such a contract has a digest, but its canonical text is not a valid source.Write [SOURCE:id] with no space after [.
E2Validation reads the top-level maxConditionDepth option. limits.maxConditionDepth is accepted, but has no effect, and the top-level option is not checked against the 256 ceiling.Lowering condition depth through limits does nothing; a very large top-level value lifts the bound.Pass maxConditionDepth at the top level, between 1 and 256.
Errata E1: a constant tagged [ SOURCE:P] is accepted, but its canonical text does not re-parseerrata-e1
CONTRACT Claim {
  ENFORCEMENT_MODE: enforced
  CONTEXT {
    ENTITIES Request {
      count: int
      region: string
      ready: bool
      ratio: float
    }
    CONSTANTS {
      zero: int == 0 [SOURCE:POLICY]
      cap: int == 25 [ SOURCE:POLICY]
    }
  }
  TRIGGER {
    grant()
  }
  GUARANTEE {
    ENSURE grant() WHEN Request.ready == true [SOURCE:must_be_ready]
  }
  PROHIBITION {
    FORBID grant WHEN Request.count > cap [SOURCE:over_cap]
  }
}

valid Claim 2 clauses · sha256 1ba3c884488e6b7df67a6335f5ba226e18b175b8194f636ac93f8dd3e570a09e

This document

DateChange
2026-10-15First publication of the v1 specification on ulang.dev, written against ulang-lite 61af4281ed.