aontu 0.50.0 → 0.51.0

package/dist/val/numkind.js

@@ -0,0 +1,224 @@
+"use strict";
+/* Copyright (c) 2025 Richard Rodger, MIT License */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.integerDigits = integerDigits;
+exports.isExactInBinary64 = isExactInBinary64;
+exports.isIntegerKind = isIntegerKind;
+exports.isIntegerStorable = isIntegerStorable;
+exports.isLossyIntegerLiteral = isLossyIntegerLiteral;
+/*
+ * Numeric kind classification, shared by every site that turns a raw
+ * JavaScript number into an IntegerVal or a NumberVal (the aontu val
+ * rule, rawToVal, VarVal, the `+` operator, upper()/lower()). Keeping
+ * the test in one place stops those sites from drifting apart, and
+ * stops them drifting from the Go port (see isIntegerKind in
+ * go/lang.go).
+ *
+ * This module deliberately imports nothing: IntegerVal itself needs the
+ * test for its constructor guard, so any import here risks a cycle.
+ */
+// The int64 range, as exact float64 bounds. -2^63 and 2^63 are both
+// exactly representable; 2^63-1 is NOT (it rounds up to 2^63), which is
+// why the upper bound is exclusive and 0x7fffffffffffffff correctly
+// falls outside.
+const INT64_MIN = -9223372036854775808.0;
+const INT64_LIMIT = 9223372036854775808.0;
+// True when a numeric literal has *integer* kind. All three conditions
+// must hold:
+//   (a) the source text, when there is any, contains no '.'
+//   (b) the value is integral
+//   (c) the value lies within the int64 range
+//
+// The range test is written against the float64 bounds rather than as
+// `n === Number(BigInt(n))` or Go's `n == float64(int64(n))`: converting
+// an out-of-range float64 to int64 is implementation-defined in Go, and
+// that accident is exactly what the two ports used to disagree about.
+//
+// `src` is undefined at construction sites with no source text (raw
+// values from an implicit top-level list, or a $var binding); there
+// condition (a) is vacuous and (b)+(c) decide.
+function isIntegerKind(n, src) {
+    if (null != src && src.includes('.')) {
+        return false;
+    }
+    // Number.isInteger is false for NaN and both infinities, so a
+    // non-finite value never reaches the range test.
+    return Number.isInteger(n) && INT64_MIN <= n && n < INT64_LIMIT;
+}
+// The same int64 window, exactly, for values that were computed as
+// bigints and have not been through a double yet.
+const INT64_MIN_EXACT = -9223372036854775808n;
+const INT64_LIMIT_EXACT = 9223372036854775808n;
+// D6 -- THE STORAGE CONTRACT FOR AN EXACTLY COMPUTED INTEGER.
+//
+// `integer + integer` is computed exactly (in bigint here, in checked
+// int64 in Go) and the exact answer is only then offered to the integer
+// leaf, which accepts it when it is integral (a bigint always is),
+// within the int64 window, AND exactly representable in binary64.
+//
+// The binary64 half is the parity-critical one. Go's int64 can hold sums
+// this port's double cannot -- 2^53+1 among them -- so a test written
+// only against the int64 window would let Go store `9007199254740993`
+// while TypeScript silently stored `...992`. The round-trip through
+// Number() is that test: it is true exactly when nothing was lost. Both
+// ports must refuse the same sums, which is why this is the shared
+// contract and not a local convenience.
+//
+// Refusal, not rounding: a sum that fails here is a located error whose
+// hint points at `0d` for an exact integer, per R1's own storage rule
+// applied to a result rather than a literal.
+function isIntegerStorable(n) {
+    return INT64_MIN_EXACT <= n && n < INT64_LIMIT_EXACT &&
+        isExactInBinary64(n);
+}
+// The binary64 half of the storage contract, on its own: true when an
+// exact integer survives a round trip through a double unchanged.
+//
+// D7's literal rule needs exactly this half and NOT the int64 window --
+// 10^20 is outside int64 and is still a perfectly good float-kind value,
+// because it lands exactly on a binary64. THE RULE IS EXACTNESS, NOT
+// MAGNITUDE: `0x10000000000000000000000000000000` is 2^124, a power of
+// two, so it is exact and stays a value, while the very much smaller
+// `0x7fffffffffffffff` (2^63-1) is not and is refused.
+//
+// It is factored out rather than reimplemented so a LITERAL and a
+// COMPUTED SUM cannot disagree about what "exact" means: both ask this
+// one function, in both ports.
+//
+// The Number.isFinite guard is what makes it total. A bigint far beyond
+// binary64's range converts to Infinity, and BigInt(Infinity) THROWS --
+// so a literal like 10^400 (which the lexer already turns into a
+// non-finite `not_number`) would crash the test rather than fail it.
+function isExactInBinary64(n) {
+    const d = Number(n);
+    return Number.isFinite(d) && BigInt(d) === n;
+}
+// D7 -- LOSSY INTEGER LITERALS ARE REFUSED.
+//
+// True when `src` is an integer-source literal whose exact value cannot
+// be held in binary64, so storing it would silently substitute a
+// DIFFERENT number. Aontu refuses instead: the caller turns this into a
+// located parse error whose hint names the escape (`0d<digits>`).
+//
+// WHICH LITERALS ARE IN SCOPE. An integer-source literal is one that
+// denotes an exact integer:
+//
+//   - plain decimal digits (`9007199254740993`), with the landed `_`
+//     separator rule;
+//   - a base-prefixed run (`0x…`, `0o…`, `0b…`);
+//   - either of those with a NON-NEGATIVE exponent (`1e21`), which still
+//     denotes an integer.
+//
+// Everything else is out of scope and unchanged. A `.` in the source
+// makes it a float literal by R1, so it is not an integer source at all;
+// a NEGATIVE exponent (`2e-1`, `1e-400`) denotes a fraction, and testing
+// those for binary64 exactness would refuse `2e-1` -- 0.2 is not exactly
+// representable either -- which is emphatically not what D7 is about.
+// The `0d` family never reaches here: it has its own matcher and its own
+// exact leaves.
+//
+// The value is re-derived from the SOURCE TEXT rather than read off the
+// lexed double `n`, because that double is the rounded value this rule
+// exists to detect; comparing it with itself would always agree. `n` is
+// passed only for the fast path, which is why the signature mirrors
+// isIntegerKind's.
+function isLossyIntegerLiteral(n, src) {
+    // No source text (a raw value from an implicit top-level list, a $var
+    // binding) means there is no literal to judge -- the same way R1's
+    // "no `.` in the source" condition is vacuous at those sites.
+    if (null == src) {
+        return false;
+    }
+    // FAST PATH, and the one every ordinary document takes: below 2^53
+    // every integer is representable, so an integer literal whose ROUNDED
+    // value is strictly inside that window cannot have had a different
+    // exact value -- a different integer would be at least 1 away, and
+    // rounding here is accurate to half a unit. This runs at every numeric
+    // literal in every parse, so it must not allocate a bigint (2^53+1 has
+    // rounded value 2^53 and is deliberately NOT inside the window).
+    if (Number.isInteger(n) && -POW53 < n && n < POW53) {
+        return false;
+    }
+    // A `.` makes it a float source (R1), out of scope: checked here, and
+    // not left to the patterns below, so the other common literal shape
+    // also leaves without touching a regexp.
+    if (-1 !== src.indexOf('.')) {
+        return false;
+    }
+    let exact;
+    const dec = DEC_INT_LITERAL_RE.exec(src);
+    if (null != dec) {
+        // A negative exponent does not denote an integer -- out of scope.
+        const exp = null == dec[3] ? 0 : Number(stripSep(dec[3]));
+        if (!(0 <= exp) || !Number.isFinite(exp)) {
+            return false;
+        }
+        const coeff = BigInt(stripSep(dec[2]));
+        // Zero at any exponent is zero, and zero is exact -- test it before
+        // the exponent bound, which would otherwise refuse `0e500`.
+        if (0n === coeff) {
+            return false;
+        }
+        // Beyond this the value cannot be finite in binary64, so it cannot
+        // be exact either -- and 10n ** BigInt(exp) must not be built.
+        if (MAX_EXPONENT < exp) {
+            return true;
+        }
+        exact = coeff * 10n ** BigInt(exp);
+    }
+    else {
+        const base = BASE_INT_LITERAL_RE.exec(src);
+        if (null == base) {
+            return false;
+        }
+        exact = BigInt('0' + base[2].toLowerCase() + stripSep(base[3]));
+    }
+    // The sign is irrelevant to exactness (binary64 is sign-symmetric) and
+    // is anyway lexed as the unary prefix, but accept it so the test does
+    // not depend on that.
+    return !isExactInBinary64(exact);
+}
+// `[+-]? digits [ (e|E) [+-] digits ]`, with the landed single-`_`-
+// between-digits separator rule. No `.`: that is a float source (R1).
+const DEC_INT_LITERAL_RE = /^([-+]?)([0-9](?:_?[0-9])*)(?:[eE]([-+]?[0-9](?:_?[0-9])*))?$/;
+// `[+-]? 0(x|o|b) digits`. Hex digits are the widest set, and a bad
+// digit for the base simply makes BigInt throw -- which cannot happen,
+// since the lexer only produced a token for a well-formed run.
+const BASE_INT_LITERAL_RE = /^([-+]?)0([xXoObB])([0-9a-fA-F](?:_?[0-9a-fA-F])*)$/;
+// Above this the value cannot be finite in binary64, so it cannot be
+// exact either, and 10n ** BigInt(exp) must not be built.
+const MAX_EXPONENT = 400;
+// 2^53, the point at which the integers stop being contiguous in
+// binary64 and so the first magnitude at which a literal can be lossy.
+const POW53 = 9007199254740992;
+function stripSep(s) {
+    return -1 === s.indexOf('_') ? s : s.replace(/_/g, '');
+}
+// THE SINGLE RENDERING OF AN INTEGER-KIND PEG. Every site that turns one
+// into text must call this -- so that "how many rendering sites are there?"
+// is answerable by grepping this function's callers.
+//
+// That question has been answered wrongly twice. Issue #21 was the
+// divergence where TypeScript printed 2^60 as 1152921504606847000, a
+// DIFFERENT integer that merely rounds to the same double, because a JS
+// number's toString emits the shortest decimal that round-trips (at most 17
+// significant digits) while Go printed the exact value from its int64. It
+// was closed having fixed the two sites known at the time, canon and
+// generate. A differential audit then found a THIRD (`+`'s string
+// coercion) and, while fixing that, a FOURTH (a variable used as a path
+// segment). Both were the same one-character mistake -- `String(peg)` or
+// `'' + peg` on a JS number -- at a site nobody had enumerated.
+//
+// BigInt is exact here by construction: an integer-kind peg is integral and
+// inside the int64 window (isIntegerKind, enforced by IntegerVal's
+// constructor), so the conversion cannot throw or lose anything. Below 2^53
+// nothing moves -- BigInt(n).toString() === String(n) for every safe
+// integer, and both give "0" for negative zero.
+//
+// FLOAT KIND MUST NOT COME HERE. A float's shortest form IS the right
+// answer and is what Go prints too (1e21 -> "1e+21"), so a caller must
+// select on kind, not merely on the peg being a JS number.
+function integerDigits(peg) {
+    return BigInt(peg).toString();
+}
+//# sourceMappingURL=numkind.js.map

package/dist/val/numkind.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"numkind.js","sourceRoot":"","sources":["../../src/val/numkind.ts"],"names":[],"mappings":";AAAA,oDAAoD;;QA0PlD,aAAa;QACb,iBAAiB;QACjB,aAAa;QACb,iBAAiB;QACjB,qBAAqB;AA5PvB;;;;;;;;;;GAUG;AAGH,oEAAoE;AACpE,wEAAwE;AACxE,oEAAoE;AACpE,iBAAiB;AACjB,MAAM,SAAS,GAAG,CAAC,qBAAqB,CAAA;AACxC,MAAM,WAAW,GAAG,qBAAqB,CAAA;AAGzC,uEAAuE;AACvE,aAAa;AACb,4DAA4D;AAC5D,8BAA8B;AAC9B,8CAA8C;AAC9C,EAAE;AACF,sEAAsE;AACtE,yEAAyE;AACzE,wEAAwE;AACxE,sEAAsE;AACtE,EAAE;AACF,oEAAoE;AACpE,oEAAoE;AACpE,+CAA+C;AAC/C,SAAS,aAAa,CAAC,CAAS,EAAE,GAAY;IAC5C,IAAI,IAAI,IAAI,GAAG,IAAI,GAAG,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC;QACrC,OAAO,KAAK,CAAA;IACd,CAAC;IACD,8DAA8D;IAC9D,iDAAiD;IACjD,OAAO,MAAM,CAAC,SAAS,CAAC,CAAC,CAAC,IAAI,SAAS,IAAI,CAAC,IAAI,CAAC,GAAG,WAAW,CAAA;AACjE,CAAC;AAGD,mEAAmE;AACnE,kDAAkD;AAClD,MAAM,eAAe,GAAG,CAAC,oBAAoB,CAAA;AAC7C,MAAM,iBAAiB,GAAG,oBAAoB,CAAA;AAG9C,8DAA8D;AAC9D,EAAE;AACF,sEAAsE;AACtE,wEAAwE;AACxE,mEAAmE;AACnE,kEAAkE;AAClE,EAAE;AACF,yEAAyE;AACzE,sEAAsE;AACtE,sEAAsE;AACtE,oEAAoE;AACpE,wEAAwE;AACxE,mEAAmE;AACnE,wCAAwC;AACxC,EAAE;AACF,wEAAwE;AACxE,sEAAsE;AACtE,6CAA6C;AAC7C,SAAS,iBAAiB,CAAC,CAAS;IAClC,OAAO,eAAe,IAAI,CAAC,IAAI,CAAC,GAAG,iBAAiB;QAClD,iBAAiB,CAAC,CAAC,CAAC,CAAA;AACxB,CAAC;AAGD,sEAAsE;AACtE,kEAAkE;AAClE,EAAE;AACF,wEAAwE;AACxE,yEAAyE;AACzE,qEAAqE;AACrE,uEAAuE;AACvE,qEAAqE;AACrE,uDAAuD;AACvD,EAAE;AACF,kEAAkE;AAClE,uEAAuE;AACvE,+BAA+B;AAC/B,EAAE;AACF,wEAAwE;AACxE,wEAAwE;AACxE,iEAAiE;AACjE,qEAAqE;AACrE,SAAS,iBAAiB,CAAC,CAAS;IAClC,MAAM,CAAC,GAAG,MAAM,CAAC,CAAC,CAAC,CAAA;IACnB,OAAO,MAAM,CAAC,QAAQ,CAAC,CAAC,CAAC,IAAI,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC,CAAA;AAC9C,CAAC;AAGD,4CAA4C;AAC5C,EAAE;AACF,wEAAwE;AACxE,iEAAiE;AACjE,wEAAwE;AACxE,kEAAkE;AAClE,EAAE;AACF,qEAAqE;AACrE,4BAA4B;AAC5B,EAAE;AACF,qEAAqE;AACrE,sBAAsB;AACtB,iDAAiD;AACjD,yEAAyE;AACzE,0BAA0B;AAC1B,EAAE;AACF,qEAAqE;AACrE,yEAAyE;AACzE,yEAAyE;AACzE,yEAAyE;AACzE,sEAAsE;AACtE,yEAAyE;AACzE,gBAAgB;AAChB,EAAE;AACF,wEAAwE;AACxE,uEAAuE;AACvE,wEAAwE;AACxE,oEAAoE;AACpE,mBAAmB;AACnB,SAAS,qBAAqB,CAAC,CAAS,EAAE,GAAY;IACpD,sEAAsE;IACtE,mEAAmE;IACnE,8DAA8D;IAC9D,IAAI,IAAI,IAAI,GAAG,EAAE,CAAC;QAChB,OAAO,KAAK,CAAA;IACd,CAAC;IAED,mEAAmE;IACnE,sEAAsE;IACtE,mEAAmE;IACnE,mEAAmE;IACnE,uEAAuE;IACvE,uEAAuE;IACvE,iEAAiE;IACjE,IAAI,MAAM,CAAC,SAAS,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,GAAG,CAAC,IAAI,CAAC,GAAG,KAAK,EAAE,CAAC;QACnD,OAAO,KAAK,CAAA;IACd,CAAC;IACD,sEAAsE;IACtE,oEAAoE;IACpE,yCAAyC;IACzC,IAAI,CAAC,CAAC,KAAK,GAAG,CAAC,OAAO,CAAC,GAAG,CAAC,EAAE,CAAC;QAC5B,OAAO,KAAK,CAAA;IACd,CAAC;IAED,IAAI,KAAa,CAAA;IAEjB,MAAM,GAAG,GAAG,kBAAkB,CAAC,IAAI,CAAC,GAAG,CAAC,CAAA;IACxC,IAAI,IAAI,IAAI,GAAG,EAAE,CAAC;QAChB,kEAAkE;QAClE,MAAM,GAAG,GAAG,IAAI,IAAI,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;QACzD,IAAI,CAAC,CAAC,CAAC,IAAI,GAAG,CAAC,IAAI,CAAC,MAAM,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC;YACzC,OAAO,KAAK,CAAA;QACd,CAAC;QACD,MAAM,KAAK,GAAG,MAAM,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;QACtC,oEAAoE;QACpE,4DAA4D;QAC5D,IAAI,EAAE,KAAK,KAAK,EAAE,CAAC;YACjB,OAAO,KAAK,CAAA;QACd,CAAC;QACD,mEAAmE;QACnE,+DAA+D;QAC/D,IAAI,YAAY,GAAG,GAAG,EAAE,CAAC;YACvB,OAAO,IAAI,CAAA;QACb,CAAC;QACD,KAAK,GAAG,KAAK,GAAG,GAAG,IAAI,MAAM,CAAC,GAAG,CAAC,CAAA;IACpC,CAAC;SACI,CAAC;QACJ,MAAM,IAAI,GAAG,mBAAmB,CAAC,IAAI,CAAC,GAAG,CAAC,CAAA;QAC1C,IAAI,IAAI,IAAI,IAAI,EAAE,CAAC;YACjB,OAAO,KAAK,CAAA;QACd,CAAC;QACD,KAAK,GAAG,MAAM,CAAC,GAAG,GAAG,IAAI,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;IACjE,CAAC;IAED,uEAAuE;IACvE,sEAAsE;IACtE,sBAAsB;IACtB,OAAO,CAAC,iBAAiB,CAAC,KAAK,CAAC,CAAA;AAClC,CAAC;AAGD,oEAAoE;AACpE,sEAAsE;AACtE,MAAM,kBAAkB,GACtB,+DAA+D,CAAA;AAEjE,oEAAoE;AACpE,uEAAuE;AACvE,+DAA+D;AAC/D,MAAM,mBAAmB,GACvB,qDAAqD,CAAA;AAEvD,qEAAqE;AACrE,0DAA0D;AAC1D,MAAM,YAAY,GAAG,GAAG,CAAA;AAExB,iEAAiE;AACjE,uEAAuE;AACvE,MAAM,KAAK,GAAG,gBAAgB,CAAA;AAG9B,SAAS,QAAQ,CAAC,CAAS;IACzB,OAAO,CAAC,CAAC,KAAK,CAAC,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,EAAE,CAAC,CAAA;AACxD,CAAC;AAGD,yEAAyE;AACzE,4EAA4E;AAC5E,qDAAqD;AACrD,EAAE;AACF,mEAAmE;AACnE,qEAAqE;AACrE,wEAAwE;AACxE,4EAA4E;AAC5E,0EAA0E;AAC1E,qEAAqE;AACrE,kEAAkE;AAClE,wEAAwE;AACxE,yEAAyE;AACzE,gEAAgE;AAChE,EAAE;AACF,4EAA4E;AAC5E,mEAAmE;AACnE,4EAA4E;AAC5E,qEAAqE;AACrE,gDAAgD;AAChD,EAAE;AACF,sEAAsE;AACtE,uEAAuE;AACvE,2DAA2D;AAC3D,SAAS,aAAa,CAAC,GAAW;IAChC,OAAO,MAAM,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE,CAAA;AAC/B,CAAC"}

package/dist/val/valutil.d.ts

@@ -1,2 +1,3 @@
 import { ScalarVal } from './ScalarVal';
 export declare function makeScalar(scalar: any): ScalarVal;
+export declare function makeScalarLike(scalar: any, like: any): ScalarVal;

package/dist/val/valutil.js

@@ -2,11 +2,17 @@
 /* Copyright (c) 2021-2025 Richard Rodger, MIT License */
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.makeScalar = makeScalar;
+exports.makeScalarLike = makeScalarLike;
 const err_1 = require("../err");
 const NumberVal_1 = require("./NumberVal");
+const IntegerVal_1 = require("./IntegerVal");
 const StringVal_1 = require("./StringVal");
 const BooleanVal_1 = require("./BooleanVal");
 const NullVal_1 = require("./NullVal");
+const BigIntegerVal_1 = require("./BigIntegerVal");
+const BigDecimalVal_1 = require("./BigDecimalVal");
+const Decimal_1 = require("./Decimal");
+const numkind_1 = require("./numkind");
 // TODO: move to FuncBaseVal
 function makeScalar(scalar) {
     const st = typeof scalar;
@@ -27,4 +33,33 @@ function makeScalar(scalar) {
         throw new err_1.AontuError('Not a scalar: ' + scalar);
     }
 }
+// Like makeScalar, but for a numeric result that must not narrow the
+// kind of the value it was derived from (kind contagion: upper(2) is an
+// integer 2, upper(1.1) is a number 2). `like` is the source Val whose
+// kind is being carried over; anything that is not integer kind — and
+// any result that has left the int64 range — yields a NumberVal.
+//
+// The two EXACT leaves need no `like`: unlike integer and float, which
+// share the JavaScript `number` type and so can only be told apart by
+// the value they came from, a bigint is a biginteger and a Decimal is a
+// bigdecimal. Carrying the kind is automatic because the exact result
+// types ARE the kinds — an exact ceiling of a bigdecimal is a Decimal,
+// so upper(0d1.1) is bigdecimal 0d2.0 and upper(0d5) is biginteger 0d5.
+//
+// makeScalar keeps its own contract (every number becomes a NumberVal)
+// for callers that have no kind to preserve.
+function makeScalarLike(scalar, like) {
+    if ('bigint' === typeof scalar) {
+        return new BigIntegerVal_1.BigIntegerVal({ peg: scalar });
+    }
+    if (scalar instanceof Decimal_1.Decimal) {
+        return new BigDecimalVal_1.BigDecimalVal({ peg: scalar });
+    }
+    if ('number' === typeof scalar &&
+        true === like?.isInteger &&
+        (0, numkind_1.isIntegerKind)(scalar)) {
+        return new IntegerVal_1.IntegerVal({ peg: scalar });
+    }
+    return makeScalar(scalar);
+}
 //# sourceMappingURL=valutil.js.map

package/dist/val/valutil.js.map

@@ -1 +1 @@
-{"version":3,"file":"valutil.js","sourceRoot":"","sources":["../../src/val/valutil.ts"],"names":[],"mappings":";AAAA,yDAAyD;;;AAEzD,gCAAmC;AAEnC,2CAAuC;AACvC,2CAAuC;AACvC,6CAAyC;AACzC,uCAAmC;AAGnC,4BAA4B;AAC5B,oBAA2B,MAAW;IACpC,MAAM,EAAE,GAAG,OAAO,MAAM,CAAA;IACxB,MAAM,IAAI,GAAG,EAAE,GAAG,EAAE,MAAM,EAAE,CAAA;IAE5B,IAAI,QAAQ,KAAK,EAAE,EAAE,CAAC;QACpB,OAAO,IAAI,qBAAS,CAAC,IAAI,CAAC,CAAA;IAC5B,CAAC;SACI,IAAI,QAAQ,KAAK,EAAE,EAAE,CAAC;QACzB,OAAO,IAAI,qBAAS,CAAC,IAAI,CAAC,CAAA;IAC5B,CAAC;SACI,IAAI,SAAS,KAAK,EAAE,EAAE,CAAC;QAC1B,OAAO,IAAI,uBAAU,CAAC,IAAI,CAAC,CAAA;IAC7B,CAAC;SACI,IAAI,IAAI,KAAK,MAAM,EAAE,CAAC;QACzB,OAAO,IAAI,iBAAO,CAAC,IAAI,CAAC,CAAA;IAC1B,CAAC;SACI,CAAC;QACJ,MAAM,IAAI,gBAAU,CAAC,gBAAgB,GAAG,MAAM,CAAC,CAAA;IACjD,CAAC;AACH,CAAC"}
+{"version":3,"file":"valutil.js","sourceRoot":"","sources":["../../src/val/valutil.ts"],"names":[],"mappings":";AAAA,yDAAyD;;;;AAEzD,gCAAmC;AAEnC,2CAAuC;AACvC,6CAAyC;AACzC,2CAAuC;AACvC,6CAAyC;AACzC,uCAAmC;AACnC,mDAA+C;AAC/C,mDAA+C;AAC/C,uCAAmC;AACnC,uCAAyC;AAGzC,4BAA4B;AAC5B,oBAA2B,MAAW;IACpC,MAAM,EAAE,GAAG,OAAO,MAAM,CAAA;IACxB,MAAM,IAAI,GAAG,EAAE,GAAG,EAAE,MAAM,EAAE,CAAA;IAE5B,IAAI,QAAQ,KAAK,EAAE,EAAE,CAAC;QACpB,OAAO,IAAI,qBAAS,CAAC,IAAI,CAAC,CAAA;IAC5B,CAAC;SACI,IAAI,QAAQ,KAAK,EAAE,EAAE,CAAC;QACzB,OAAO,IAAI,qBAAS,CAAC,IAAI,CAAC,CAAA;IAC5B,CAAC;SACI,IAAI,SAAS,KAAK,EAAE,EAAE,CAAC;QAC1B,OAAO,IAAI,uBAAU,CAAC,IAAI,CAAC,CAAA;IAC7B,CAAC;SACI,IAAI,IAAI,KAAK,MAAM,EAAE,CAAC;QACzB,OAAO,IAAI,iBAAO,CAAC,IAAI,CAAC,CAAA;IAC1B,CAAC;SACI,CAAC;QACJ,MAAM,IAAI,gBAAU,CAAC,gBAAgB,GAAG,MAAM,CAAC,CAAA;IACjD,CAAC;AACH,CAAC;AAGD,qEAAqE;AACrE,wEAAwE;AACxE,uEAAuE;AACvE,sEAAsE;AACtE,iEAAiE;AACjE,EAAE;AACF,uEAAuE;AACvE,sEAAsE;AACtE,wEAAwE;AACxE,sEAAsE;AACtE,uEAAuE;AACvE,wEAAwE;AACxE,EAAE;AACF,uEAAuE;AACvE,6CAA6C;AAC7C,wBAA+B,MAAW,EAAE,IAAS;IACnD,IAAI,QAAQ,KAAK,OAAO,MAAM,EAAE,CAAC;QAC/B,OAAO,IAAI,6BAAa,CAAC,EAAE,GAAG,EAAE,MAAM,EAAE,CAAC,CAAA;IAC3C,CAAC;IACD,IAAI,MAAM,YAAY,iBAAO,EAAE,CAAC;QAC9B,OAAO,IAAI,6BAAa,CAAC,EAAE,GAAG,EAAE,MAAM,EAAE,CAAC,CAAA;IAC3C,CAAC;IACD,IAAI,QAAQ,KAAK,OAAO,MAAM;QAC5B,IAAI,KAAK,IAAI,EAAE,SAAS;QACxB,IAAA,uBAAa,EAAC,MAAM,CAAC,EAAE,CAAC;QACxB,OAAO,IAAI,uBAAU,CAAC,EAAE,GAAG,EAAE,MAAM,EAAE,CAAC,CAAA;IACxC,CAAC;IACD,OAAO,UAAU,CAAC,MAAM,CAAC,CAAA;AAC3B,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aontu",
-  "version": "0.50.0",
+  "version": "0.51.0",
   "main": "dist/aontu.js",
   "type": "commonjs",
   "types": "dist/aontu.d.ts",
@@ -47,13 +47,13 @@
     "LICENSE"
   ],
   "dependencies": {
-    "@tabnas/debug": "0.3.0",
-    "@tabnas/directive": "0.5.0",
-    "@tabnas/expr": "0.5.0",
+    "@tabnas/debug": "0.3.1",
+    "@tabnas/directive": "0.5.1",
+    "@tabnas/expr": "0.5.1",
     "@tabnas/jsonic": "0.6.0",
-    "@tabnas/multisource": "0.5.0",
-    "@tabnas/parser": "0.8.0",
-    "@tabnas/path": "0.3.0"
+    "@tabnas/multisource": "0.5.1",
+    "@tabnas/parser": "0.8.4",
+    "@tabnas/path": "0.3.1"
   },
   "devDependencies": {
     "@types/node": "26.1.1",

package/src/aontu.ts

@@ -9,6 +9,8 @@ import { Lang } from './lang'
 import { Unify } from './unify'
 import { AontuContext, AontuContextConfig } from './ctx'
 import { MapVal } from './val/MapVal'
+import { Decimal } from './val/Decimal'
+import { exactJSON } from './exactjson'
 import { formatExplain } from './utility'
 import { makeNilErr, descErr, AontuError } from './err'
 
@@ -20,7 +22,7 @@ import { makeNilErr, descErr, AontuError } from './err'
 // Kept in step with package.json by the `version` npm lifecycle script,
 // which runs on `npm version` / `npm run repo-bump`. version.test.ts
 // fails if the two ever drift.
-const VERSION = '0.50.0'
+const VERSION = '0.51.0'
 
 
 class Aontu {
@@ -127,6 +129,18 @@ class Aontu {
 
 
   // Generate output structure from source, which must parse and fully unify.
+  //
+  // The result is made of NATIVE values, and D9 puts two beyond what
+  // `JSON.stringify` can write: a `biginteger` (a `0d` literal with no
+  // fraction or exponent) generates as a native `bigint`, and a
+  // `bigdecimal` generates as a `Decimal`. Both are exact at any
+  // magnitude, which is the whole point of the leaves -- and both are
+  // confined to documents that opt in, so a `0d`-free document generates
+  // exactly what it always did.
+  //
+  // Serialise the result with `exactJSON` (exported alongside this
+  // class), NOT with `JSON.stringify`: the latter throws on a bigint and
+  // has no way to write exact digits as a JSON number.
   generate(src: string, opts?: any, ac?: AontuContext): any {
     try {
       let out = undefined
@@ -239,7 +253,14 @@ export {
   Lang,
   runparse,
   util,
-  formatExplain
+  formatExplain,
+
+  // D9 -- the generate contract. `exactJSON` is the supported way to
+  // turn `generate()` output into JSON when a document uses the exact
+  // leaves, and `Decimal` is the type a `bigdecimal` generates as (a
+  // `biginteger` generates as the language's own `bigint`).
+  exactJSON,
+  Decimal,
 }
 
 

package/src/cli.ts

@@ -13,7 +13,7 @@ import * as Fs from 'node:fs'
 import * as Path from 'node:path'
 import * as Readline from 'node:readline'
 
-import { Aontu, AontuError } from './aontu'
+import { Aontu, AontuError, exactJSON } from './aontu'
 
 
 type Mode = 'json' | 'canon'
@@ -57,9 +57,15 @@ function evalSource(
   mode: Mode,
 ): { ok: boolean; text: string } {
   try {
+    // exactJSON, not JSON.stringify: a document using the `0d` exact
+    // leaves generates bigints and Decimals, which JSON.stringify cannot
+    // write (D9). The CLI prints INDENTED JSON and the shared suite's
+    // `gens` mode prints COMPACT JSON, but both go through this one
+    // emitter -- an indent argument rather than a second implementation,
+    // so the two cannot drift from each other or from the Go port.
     const text = 'canon' === mode
       ? aontu.unify(src).canon
-      : JSON.stringify(aontu.generate(src), null, 2)
+      : exactJSON(aontu.generate(src), 2)
     return { ok: true, text }
   }
   catch (err: any) {
@@ -142,11 +148,33 @@ function runRepl(initialMode: Mode): void {
 
   rl.on('close', () => {
     process.stdout.write('\n')
-    process.exit(0)
+    // Same reason as finish(): the REPL requires a TTY stdin, but stdout
+    // can still be a pipe (`aontu | cat`), so exiting outright could
+    // discard queued output here too.
+    process.exitCode = 0
   })
 }
 
 
+// Exit without truncating output.
+//
+// process.exit() terminates immediately, discarding anything still
+// queued on stdout. A write to a PIPE is asynchronous once it exceeds
+// the pipe buffer, so `write(big); exit(0)` silently truncated output at
+// 65536 bytes — while a write to a TTY or a file, being synchronous,
+// looked fine. Setting exitCode instead lets the process end naturally,
+// after the queue drains.
+//
+// This predates the exact leaves but they make it trivially reachable
+// (one long biginteger canon exceeds the buffer), and it lands squarely
+// on the parity-probe discipline in AGENTS.md, which derives expected
+// spec values by piping BOTH CLIs and comparing. A truncated pipe there
+// reads as a port divergence.
+function finish(code: number): void {
+  process.exitCode = code
+}
+
+
 function main(argv: string[]): void {
   let mode: Mode = 'json'
   let file: string | undefined
@@ -157,15 +185,15 @@ function main(argv: string[]): void {
     }
     else if ('-h' === arg || '--help' === arg) {
       process.stdout.write(HELP)
-      process.exit(0)
+      return finish(0)
     }
     else if ('-v' === arg || '--version' === arg) {
       process.stdout.write(version() + '\n')
-      process.exit(0)
+      return finish(0)
     }
     else if (arg.startsWith('-')) {
       process.stderr.write(`aontu: unknown option ${arg} (try --help)\n`)
-      process.exit(2)
+      return finish(2)
     }
     else {
       file = arg
@@ -173,13 +201,13 @@ function main(argv: string[]): void {
   }
 
   if (null != file) {
-    process.exit(runFile(file, mode))
+    finish(runFile(file, mode))
   }
   else if (process.stdin.isTTY) {
     runRepl(mode)
   }
   else {
-    runStdin(mode).then((code) => process.exit(code))
+    runStdin(mode).then((code) => finish(code))
   }
 }