Joseph Ferano
335e817676
Refusing every defconst was right about the class and wrong about most of the instances. A constant the checker consumed - (defconst rows (/ h c)), which decides grid's type before anything else resolves - is in the shape of the program and no store can reach it. A constant that is only ever read at run time is just bytes in memory. sand's colors is the second kind, and tuning a colour table live is exactly the thing you would want a dev loop for. So a dev build emits every defconst as a mutable global rather than a constant. LLVM can then no longer fold a read of it and a module can store into it, and a changed one is published at the frame boundary the same way a new function body is. Release builds emit constant and get all the folding back. Tast.global.gfolded records which kind it is, because nothing downstream of the checker can tell: env.consts holds exactly the constants the folding pass consumed, and membership is the question "is this value in the program's shape?". The session keys its refusal on that, with a message that says what the constant is used for rather than just that it changed. Verified against a running sand: sim/colors is accepted, sim/rows is refused and says why.
39 lines
1.7 KiB
Plaintext
39 lines
1.7 KiB
Plaintext
;;;; The reload primitive's fixture, v1 (NEXT.md, dev loop step 1 and 2).
|
|
;;;;
|
|
;;;; There is deliberately no [main]: the host is reload_host.c, which links
|
|
;;;; this program and then dlopens two rebuilt copies of [bump].
|
|
;;;;
|
|
;;;; [counter] is the state that has to survive a reload — a redefinition
|
|
;;;; module declares it [external], so the loaded object writes the host's copy
|
|
;;;; and not a new one. [outer] is the call site that has to *follow* a reload:
|
|
;;;; it is compiled once, into the host, and never rebuilt, so if a redefined
|
|
;;;; [bump] runs when the host calls [outer] then the cell is doing its job.
|
|
;;;; The string is not decoration either — a redefinition module has to carry
|
|
;;;; its own constants, and a one-function module usually has none.
|
|
(defvar counter i64)
|
|
|
|
;;; Unused, and that is the point: the session's compatibility rules only get a
|
|
;;; chance to speak about a change the *checker* accepts, and retyping a var
|
|
;;; something else reads is an ordinary type error long before it is a layout
|
|
;;; question.
|
|
(defvar spare i64)
|
|
|
|
;;; Also unused, and for the same reason: a defconst's value and an enum
|
|
;;; member are folded into every call site, so a session has to refuse changing
|
|
;;; either. Nothing here reads them, so the checker has no opinion and the
|
|
;;; session's rule is the only thing that can speak.
|
|
(defconst folded i64 7)
|
|
;;; ...and one that is not: an array constant is never an array length, so its
|
|
;;; value is only ever read at run time and a dev build can store a new one.
|
|
(defconst palette [2 u32] [1 2])
|
|
(defenum Colour [red 0 green 1])
|
|
|
|
(defn helper [x i64] i64 (* x 2))
|
|
|
|
(defn bump [] i64
|
|
(print-line "v1")
|
|
(set counter (+ counter 1))
|
|
(helper counter))
|
|
|
|
(defn outer [] i64 (bump))
|