I've been noticing continuities between social code distribution, modularity, and variable scope. A guiding example is code verification:
Unrecorded reasoning, existing mainly in our minds.
-->
Codebases dedicated to proofs or tests.
-->
Proofs or tests located in the codebase they apply to.
-->
A type/contract declaring a module interface.
-->
A type/contract annotation for a function definition.
-->
A type/contract annotation for an individual expression.
-->
A type/contract annotation for an individual built-in operator, but at
this point it becomes implicit in the operator itself, and we just
have structured programming, enjoying properties by construction.
Verification is a simplified version of a build process; it's just a build with a yes or no answer. So the design of a build system has similar continuity:
Unrecorded how-to knowledge, existing mainly in our minds.
-->
Codebases or how-to guides dedicated to curated builds (e.g. distros).
-->
Build scripts and docs located in the codebase they apply to.
-->
Macroexpansion-time glue code, importing compiler extensions by name.
-->
Load-time glue code, importing runtime extensions by name.
-->
Service-startup-time glue code, obtaining dependency-injected fields
by name.
-->
An expression, taking free variables from its lexical scope by name.
(This is a build at "evaluation of this particular expression" time.)
There might be some rough parts in here. I might be taking things for granted that I don't want to, like taking for granted that we want unambiguous named references from one module to another. My point with this continuity is to note that if I don't want named imports, then maybe I don't want named local variables either; maybe tweaks to one design should apply to the other.
And this means that even local syntactic concerns extrapolate to social decisions about how we expect to deal with our unrecorded knowledge. Every design decision has a lot to go by. :)
---
Another exciting part is that I think nested quasiquotation shows us a more general theory of lexical locality. If we're dealing with syntax as text, then locations in that text have an order, and we can isolate code snippets at intervals along that order (and mark them with parentheses). Intervals are partially ordered by containment, so we can isolate code snippets at meta-intervals between an outer interval and multiple nonoverlapping inner intervals (and mark them with parentheses with nonoverlapping parentheses-shaped holes: quasiquotations).
That "nonoverlapping" part seems awkward, but I think there's a simple concept somewhere in here.
With this concept of intervals, I'm considering higher degrees of lexical structure past quasiquotation, and I'm considering what kind of parentheses or quasiquotations would exist for non-textual syntaxes.
A module system deals with a non-textual syntax: The syntax of a bundle of modules. If the modules have no order to them, then we don't even have parentheses to work with, let alone quasiquotation. But they can have an order to them. We can impose one from outside:
Module A precedes module B.
And anything we can impose from outside, we might want to add as a module:
Module A says, "..."
Module B says, "..."
Module C says, "Module A precedes module B."
This is prone to contradictions and ambiguities. If we can say how to resolve these ambiguities from the outside, we should be able to do so as a module:
Module A says, "..."
Module B says, "..."
Module C says, "Module A precedes module B."
Module D says, "Module B precedes module A."
Module E says, "If module C and module D disagree, listen to module C."
Module F says, "If module C and module D disagree, listen to module D."
Module G says, "If module E and module F disagree, listen to module E."
This should lead to a very complete system of closed-system extensibility: For any given set of modules, if the set's self-proclaimed ordering between A and B is currently unambiguous, then we might as well listen to it! If we don't like it, we can add more contradictions and disambiguations until we do, right up to and including "Ignore all those other modules and do it like this." :)
With this ability to disambiguate when things go wrong, we can model lexical scope:
Module A says, "Export foo = (import bar from system {B, C})."
Module B says, "Export foo = 2."
Module C says, "Export bar = foo + foo."
Result: foo = 4.
While both A and B have an export named "foo," this conflict is disambiguated by the fact that module A is treating {B, C} as a local scope. I intend this to mean that bar isn't at the top level either.
If we really want access to bar at the top level, we can refer to it again, and we can even be sloppy about it and make up for our sloppiness with disambiguations:
Module A says, "Export foo = (import bar from system {B, C})."
Module B says, "Export foo = 2."
Module C says, "Export bar = foo + foo."
Module D says, "Export all imports from system {B, C}."
Module E says, "If A and D export the same variable, listen to A."
Result: foo = 4; bar = 4.
If we want, we can have the top-level bar see the version of foo exported by A, even though the version of bar used by A still uses the foo from B:
Module A says, "Export foo = (import bar from system {B, C})."
Module B says, "Export foo = 2."
Module C says, "Export bar = foo + foo."
Module D says, "Export all imports from system {A, B, C}."
Module E says, "Export all imports from system {C, F}."
Module F says, "Export foo = (import foo from system {A, B, C})."
Module G says, "If D and E export the same variable, listen to D."
Result: foo = 4; bar = 8.
Not easy enough to extend? Define some structure. Write modules that assign folksonomic tags to other modules or themselves, and then refer to the system of all modules with a given tag. Write modules that act as parentheses, and write modules that determine enough of an order to decide which modules those parentheses contain. Here's an example of the latter:
Module A says, "Export foo = (import bar from range R1)."
Module B says, "Export interval R1, and begin it here."
Module C says, "Export foo = 2."
Module D says, "Export bar = foo + foo."
Module E says, "End interval."
Module F says, "These modules are in order: B, C, D, E."
The flexibility is obviously really open-ended here, and it's going to be a challenge to make this a well-defined idea. :-p
