Four corrections to the prose and one to the test, none to the design.
The provenance line said "the name is Rust's or_else, the behaviour is
Rust's unwrap_or", which conflates two functions that differ in both
eagerness and return type — Rust's or_else takes a closure and answers
another Option. Java's Optional.orElse is the exact match, and its lazy
sibling orElseGet is the one already declined a paragraph above.
The helper reaching or-else's None branch at an owning type asserted a
refusal nobody had run. Compiled, it is "nothing here says what None is
an Option of — annotate the function's return type or the binding", so
the comment quotes that and the helper is a return type and nothing
else: its other branch was never called, in a program whose header says
every line is a claim.
read-file's comment claimed both restarts arrive unchanged and the test
runs use-value. Narrowed to the mechanism (nothing here establishes a
handler) plus the half that is actually executed.
And edn-read.flan now says what becomes of its defn wrapper when the
computed-initialiser work lands, since that is the only thing keeping
the motivating line from being written as the defvar.
Joseph Ferano
f35af50f51