# 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
```