Engine fidelity

Every module of both editions was loaded in the browser engine (SCI, from the unmodified source) and compared with the JVM engine (Clojure 1.7.0 on Java 8) loading the same module: its printed output, every clock agent's sealed value, and a call of every public function with the same arguments (24.5 7 3 2 1 0.5, as many as each arity takes). Each module's clock was frozen at the instant the JVM loaded it, so sealed values can be compared. ← back to the engine

What differs, and why

• Number printing. JavaScript has one number type. A double with an integral value prints without its .0 (16800 for the JVM's 16800.0); a large value prints in full (14227095.359168053 for the JVM's 1.4227095359168053E7); there are no exact ratios, so (/ 1000 7) is 142.85714285714286, not 1000/7. Values agree; their printed form does not.
• Integers are exact to 2⁵³ rather than 2⁶³. The engine's day and millisecond counts sit far inside that.
• Character literals. ClojureScript has no character type. A bare \n in the source — which Clojure reads as the letter n, not a newline — is the one-letter string "n", and prints as such where the JVM prints \n.
• Clocks. Agents seal to this device's clock at the moment of loading, and re-seal whenever the page is reloaded. Functions that read the clock when called (*ztnldy*) return the reading of that moment.
• Dates, read from Nsukka. The engine writes every date as (c/from-long (long (+ ORIGIN (* 86400000 Z)))), and the JVM printed that uniform epoch in UTC. Here each date is the instant at which the Nsukka/Yg clock reads the same Z: the engine's own year, Yg = 17640/48.3 days (sfo10), laid on Nsukka's calendar from 1 December 00:00 and recalibrated at every Yg year, printed in Nsukka time (+01:00). A Z in the 5/23 day passed over at a recalibration prints no instant; one in the 18/23 day met twice prints both. local-now prints Nsukka time on any device. The comparison reads each JVM date through the same rule, so every date it printed is checked against its Nsukka/Yg instant.
• Error wording. Failures raise the JVM's exception where the engine's behaviour depends on it (ClassCastException for arithmetic on an agent; Agent is failed, needs restart). Other errors carry SCI's wording: 24.5 is not ISeqable for the JVM's Don't know how to create ISeq from: java.lang.Double.
• Object identities. #object[… 0x2652b145 …] hashes differ on every run, on the JVM as well.

Reproduce: tools/capture_jvm.py against the running JVM engine, then node tools/compare.js primary|bank.