| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'default-scope' is now 'default-space'
'closure-generator' is now 'next-space-generator'
The connection to high-level syntax for closures is now tenuous, so
we'll call the 'outer scope' the 'next space'.
So, let's try to create a few sentences with all these related ideas:
Names map to addresses offset from a default-space when it's provided.
Spaces can be strung together. The zeroth variable points to the next
space, the one that is accessed when a variable has /space:1.
To map a name to an address in the next space, you need to know what
function generated that space. A corollary is that the space passed in
to a function should always be generated by a single function.
Spaces can be used to construct lexical scopes and objects.
|
| | |
|
| | |
|
| |
|
|
|
| |
We expect users to come across mu from arbitrary bits of code, so try to
make each line as self-contained as possible.
|
| |
|
|
|
|
| |
This pollutes our traces with all 'system software'. Too much trouble to
keep it out; just lump it for now. Who knows, might even be useful. Most
of the time convert* labels are easy to grep out when debugging.
|
|
|
Will the 'lightweight tools' really be all that useable if we encourage
people to layer them one atop another and track precisely what inputs
each can accept? Something to keep an eye on.
In the meanwhile, we have a new (but very unrealistic) example
demonstrating the tangling directives.
There's still a big constraint on ordering: before/after clauses have to
come before functions that need them.
|