A TypeScript reader brings habits from objects, structural types, unions, undefined, promises, imports, npm packages, and prototype-shaped history. That helps with flexible shapes and fast feedback from type tooling, but the Musi page asks a narrower question: what contract should this named cases and pattern matching example make visible?
type TrafficLight = "red" | "yellow" | "green";
const canWalk = (light: TrafficLight) => light === "green";let TrafficLight := data {
| Red
| Yellow
| Green
};
let canWalk (light : TrafficLight) : Bool :=
match light (
| .Green => 0 = 0
| _ => 0 = 1
);Reading Unions, Variants, and Pattern Matching from JavaScript/TypeScript
On the Musi side, Musi data variants name the cases directly, and match reads the case split at the point where the answer is chosen. Read the shared example through JavaScript/TypeScript eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not keep integer tags, string unions, subclass checks, or table marker fields when a data variant is the real shape. For a TypeScript reader, the trap is assuming runtime object shape and compile-time behavior contract are the same thing; Musi class is not a JS constructor or TS class; it is a behavior contract implemented separately from record/data shape.
When this pays off
Use data variants when an order, animal, traffic light, payment state, or parser result has a closed set of cases. The JavaScript/TypeScript instinct still helps here: Keep the TypeScript habit of reading the shape before reading implementation details.