Joseph Ferano
a4c6b996ff
The trio the author decided on 2026-09-20 is now all built: def is CL's defparameter — its initialiser runs on every daemon re-run, unguarded, so an edited initialiser repaints the same storage on C-c C-c plus re-run — defonce (Clojure's name for CL's defvar, per the author) initialises once behind the .init~once. flag, and defconst stays the image. One parse arm reads both forms; the difference is Ast.reinit, carried to Tast.global's grerun. Emit.startup_plan gives a def no guard flag, and Check.check_global lifts every def initialiser — zero and literal included — into global/<n>, so the host's startup reaches it through the function cell and a re-evaluated def swaps it (Session's def_inits; Emit.redefinition declares the cell for a non-sibling target). The old defvar spelling is refused with the rename and both compiling spellings, and every program, test, doc and editor list is swept — except sand.flan, the author's live WIP, whose seven defvar lines are flagged in FIX.org and keep its three dependent tests red on this branch.
43 lines
1.4 KiB
Plaintext
43 lines
1.4 KiB
Plaintext
;;;; The boundary in both directions, and the trap when a claim is wrong.
|
|
;;;;
|
|
;;;; Typed to dyn is implicit: take-dyn is called with an i64 and the boxing is
|
|
;;;; written nowhere. Dyn to typed is not: take-i64's parameter says i64, and
|
|
;;;; that annotation is the whole of why the unboxing is allowed to happen —
|
|
;;;; and the whole of why it may fail, which the last line of main proves by
|
|
;;;; handing it a float.
|
|
;;;;
|
|
;;;; A let carries no type in this language, so the annotation sites a dyn can
|
|
;;;; be unboxed at are the ones that do: a parameter, a return type, and a
|
|
;;;; global's declared type. All three are here.
|
|
|
|
(defonce seven i64 7)
|
|
(defonce boxed dyn 21)
|
|
;; The other direction at a global: a dyn initialiser meeting a written type.
|
|
(defonce unboxed i64 boxed)
|
|
|
|
(defn take-dyn [d dyn] dyn
|
|
(+ d 100))
|
|
|
|
(defn take-i64 [n i64] i64
|
|
(* n 2))
|
|
|
|
(defn identity-dyn [d] dyn d)
|
|
|
|
;; A dyn value answered at a written return type, which is the third site.
|
|
(defn as-i64 [d] i64 d)
|
|
|
|
(defn main [] ()
|
|
;; Typed in: the i64 is boxed at the call with nothing written.
|
|
(print (take-dyn seven))
|
|
(print "\n")
|
|
;; Dyn out: the parameter is typed, so the word is unboxed at the call.
|
|
(print (take-i64 boxed))
|
|
(print "\n")
|
|
(print unboxed)
|
|
(print "\n")
|
|
(print (as-i64 (identity-dyn 5)))
|
|
(print "\n")
|
|
;; And the claim that is wrong. The runtime owns the message.
|
|
(print (take-i64 (identity-dyn 1.5)))
|
|
(print "\n"))
|