bigmerge
c6ba0677f0
cycles/ one file per Ishikawa -> scientific method -> Six Sigma loop, named
for the DEFECT not the fix, carrying the commit record as written at
the time
findings/ what the cycles produced, cross-cut: live bugs, architecture answers,
and defects in my own measurement
The organising finding is that predictions which came back FALSE produced every
significant result. Eleven of sixty-one failed, and those eleven found: that the
arity table was not drifted but 40% incomplete; that the AST traversal is
irreducible and only rules and judgments move; that guards could refuse through
the seam after all; and that routing el_bin_lookup through the gate did NOT fix
the SIGSEGV, because the fallback strlen was the hazard -- a wrong fix I would
otherwise have shipped as verified.
One cycle was run without committing predictions first and had to be discarded
as rigged. It is kept, in full, as 18-async-half-expressible.md.
54 lines
2.0 KiB
Markdown
54 lines
2.0 KiB
Markdown
# no namespacing at all
|
|
|
|
One `Ishikawa → scientific method → Six Sigma` loop. The record below is the
|
|
commit message as written at the time, before the outcome was known to anyone
|
|
reading this file.
|
|
|
|
## Record — `79f6cb7`
|
|
|
|
```
|
|
ANSWER: if the partition is a neighbourhood, does linking survive?
|
|
|
|
The question is premature, and measuring says why. El's partition is a
|
|
FILESYSTEM PATH, not a neighbourhood, and there is no namespacing at all.
|
|
|
|
MEASURED
|
|
import is textual inlining (resolve_imports), guarded against double
|
|
inclusion by a __elc_imp__:<path> state key
|
|
when a .elh header exists the header is inlined instead and the .el is marked
|
|
seen, so symbols resolve at C link time -- so linking IS real, delegated to C
|
|
two modules defining `helper` emit two C functions into one translation unit
|
|
|
|
So linking barely survives the PATH partition. Whether it survives a
|
|
neighbourhood partition cannot be asked yet.
|
|
|
|
A DIAGNOSTIC REGRESSION I CAUSED, found by asking this question. cc does catch
|
|
the collision, but reports:
|
|
|
|
error: redefinition of '__el_body_helper'
|
|
error: redefinition of '__env_helper'
|
|
error: redefinition of '__thunk_helper'
|
|
error: redefinition of 'helper'
|
|
|
|
The user's own function is FOURTH. The first three are generated symbols
|
|
introduced by the unconditional-wrapper pass earlier today -- before it, there
|
|
was one clear message. Repaired by catching the collision at El level instead:
|
|
|
|
duplicate definition: 'helper' is defined 2 times — El has no namespacing,
|
|
so imported modules share one global scope
|
|
|
|
LIMIT, stated rather than hidden: textual inlining destroys file provenance. By
|
|
the time codegen runs there is one source string, so the message can say WHICH
|
|
name collides but not which files. Naming a.el and b.el needs provenance
|
|
threaded through resolve_imports.
|
|
|
|
104/104 native, 4/4 definitions_query.sh, the compiler itself reports clean,
|
|
fixpoint ok.
|
|
```
|
|
|
|
## Record — `f23cb2b`
|
|
|
|
```
|
|
answer the module question: the partition is a path, and there is no namespacing
|
|
```
|