Naming considerations

Contents

How a Program becomes TypeScript, in parts. Start with the introduction, then follow each part into the rendered output and the runtime it links against.

• Introduction — what the TypeScript target is, and how to read the rest of this section.
• Capabilities — which high-level features are possible, built in or through a library.
• Example — a full program using every keyword, and the TypeScript it renders to.
• Naming considerations — how Program's dotted names are carried into TypeScript.
• Entry point — starting a program and attaching it to a root element.
• Drivers — the native drivers that provide the interface, animation and network.
• Runtime — the Reactive and Context machinery the rendered code links against.
• Native modules — the hand-written JavaScript behind NATIVE functions.
• Keywords — how each of Program's keywords renders to TypeScript.
• Project setup — the files and commands to build and run the rendered program.
• Reserved words — the words TypeScript keeps for itself, and how a colliding name is escaped.

How it looks

Like JavaScript, the dotted name is kept exactly as written — and because TypeScript has real namespaces, the same path works as a type too.

const p: App.Profile = App.Profile /* … */;        // value and type, both dotted
Ui.Button.Integer.Increment(count, () => { … });   // verbatim

The natural idiom

Idiomatic TypeScript today leans on ES modules and named imports rather than namespace, which would discard the dotted shape. But TypeScript never removed namespaces, and they are exactly the right tool for mirroring Program's tree.

Keeping the real dotted name

Each namespace segment becomes a nested TypeScript namespace; the leaf is an export inside it. This gives a genuine dotted path at both levels: a function call and a type reference read the same as in Program, and the compiler resolves them natively.

namespace Ui {
  export namespace Button {
    export namespace Integer {
      export function Increment(count: ReactiveValue<number>, body: () => void): void { … }
    }
  }
}

// value: dotted, checked
Ui.Button.Integer.Increment(count, () => { … });
// type: also dotted
let s: App.Profile;

A built-in value type folds to a native annotation instead of a namespace — Maths.Integer is number, Text is string. A record TYPE you define is a class named by its dotted path.

Recommendation

Use nested namespaces directly. It is the one target where the dotted name survives at both the value and the type level with no compromise; the tradeoff is only that the output uses a feature some style guides discourage, which is a fair price for names that match the source exactly. The only identifiers ever rewritten are ordinary variables that collide with a reserved word.