edn-provide.flan reads assets/edn/tileset.edn through a struct derived from it,
and its first five lines are edn-read.flan's first five character for character.
Two readers over one file agreeing is what says the derived one is right; either
alone could be self-consistently wrong. The pair memberships are the derivation
deciding in public: the set became a (Map [2 i64] bool), so [3 4] is a key and
[9 9] is not, where a version that made it 108 loose integers would have
compiled and answered differently on all four.
A tuning file beside it covers the rest of the matrix — a string, an integer, a
float, a boolean, a vector summed rather than counted, and a map inside a map
read two field loads deep — and then drift: the struct was derived from a file
with :speed and without :level, and the bytes read carry the opposite. Both are
named, and the read carries on.
The refusals write their own data file, because the data file is the test. Each
is asserted on the position it names, not on the fact of failing, and one of
them checks a line and column into a file the compiler is not reading — which
is the whole of what compile-error was added for.
Two things the tests caught. Load extends the ambient macro set rather than
replacing it, so a package reached twice handed its declarations over twice and
the module refused them as a redefinition; Macro.compile dedupes by name, which
is the rule macro_union already applies a level up. And `where` held a line and
a column at once, which the prelude's note over append-i64 says cannot be done:
i64->bytes renders into one shared static buffer, and both numbers read as the
second one.
(edn/defedn Tileset "assets/tileset.edn") reads the file while the program is
being compiled, derives the struct its shape implies, and emits that struct
with a reader over the tokenizer next door. From there (.texture-path data) is
a field load: no Value, no match, no runtime tag, nothing looked up by name.
The real game file is the case it was built against, and its set of [x y] pairs
is why a vector inside a set becomes a fixed array rather than a Vec — a set is
this repo's (Map T bool), so its elements are map keys, and [2 i64] is one
where (Vec i64) is not.
Two things found while writing it. A quasiquote inside a package's ordinary
function was not qualified — only a defmacro's body goes through
qualify_macro — so a (defn ... [c (Ptr Cursor)] ...) emitted from a derivation
helper reached the importer naming a type it had never heard of. The name
survives into a string, which is the property the expander depends on and
exactly what puts it out of a rename's reach; load.ml now qualifies a literal
(Form.Sym {.s "..."}) naming something the package owns. Until a package's
macros could call the package's functions there was no helper that built code,
so this could not have shown before.
And (vec-new) and (map-new) have to be told what they build by naming a type,
which (Vec i64) and [2 i64] have no way to be. Both fall back to what the
context wants and a signature is a type position, so each collection gets a
one-line constructor stating its type. The reader reads better for it.
