js-on-sx: expression statements support comma operator
Some checks failed
Test, Build, and Deploy / test-build-deploy (push) Failing after 43s

This commit is contained in:
2026-05-09 10:19:24 +00:00
parent d145532afe
commit 3e8aae77d5
2 changed files with 3 additions and 1 deletions

View File

@@ -1417,7 +1417,7 @@
((jp-at? st "keyword" "switch") (jp-parse-switch-stmt st))
(else
(let
((e (jp-parse-assignment st)))
((e (jp-parse-comma-seq st)))
(do (jp-eat-semi st) (list (quote js-exprstmt) e)))))))
(define

View File

@@ -158,6 +158,8 @@ Each item: implement → tests → update progress. Mark `[x]` when tests green.
Append-only record of completed iterations. Loop writes one line per iteration: date, what was done, test count delta.
- 2026-05-09 — **Top-level expression statements support the comma operator.** Was using `jp-parse-assignment` for the expression in `jp-parse-stmt`'s fallback branch, so `false, true;` raised "Unexpected token: punct ','". Switched to `jp-parse-comma-seq`, which already returns either a plain assignment (no comma seen) or a `js-comma` AST. Per spec, ExpressionStatement → Expression, and Expression includes the comma operator. Result: language/expressions/comma 1/5 → 3/5, language/statements 22/30 → 23/30. Object/Array/Map unchanged. conformance.sh: 148/148.
- 2026-05-09 — **`instanceof` accepts function operands.** `js-instanceof` was returning false on the very first check `(not (= (type-of obj) "dict"))` for any non-dict left-hand side — but functions are objects too, so `MyFunct instanceof Function` should be true (functions inherit from `Function.prototype`) and `MyFunct instanceof Object` likewise. Added a `js-function?` arm that special-cases against `Function.prototype` and `Object.prototype`, and falls through to the proto-walk if the function happens to also have a `__proto__` slot (dict-with-`__callable__` constructors do). Result: language/expressions/instanceof 20/30 → 24/30. Object 30/30, Error 22/30, Function 4/30 unchanged. conformance.sh: 148/148.
- 2026-05-09 — **Relational operators ToPrimitive their operands (string-vs-numeric decision); `<= / >=` short-circuit to false on NaN.** `js-lt` was checking only `(type-of)` for `"string"` to pick the string-compare branch, so `{} < function(){return 1}` fell into `(< NaN NaN)` (returning false) while `{}.toString() < fn.toString()` returned true (lex). Reused `js-add-unwrap` (now extended to coerce lambda/function/component to their `js-to-string` representation, matching the function's `[object Function]` / `function () { [native code] }` semantics) so both operands are first reduced to primitives. Added explicit NaN check in the numeric branch of `js-lt` and `js-le`. `js-le` no longer does `(not (js-lt b a))` — that gave the wrong answer on NaN (NaN ≤ x must be false, not !(x < NaN) = true). `js-ge` similarly switched to `(js-le b a)`. Result: language/expressions/less-than 23/30 → 24/30, greater-than 23/30 → 24/30, addition 24/30 → 25/30. Object 30/30 maintained. conformance.sh: 148/148.