Arc Forumnew | comments | leaders | submitlogin
4 points by rocketnia 2143 days ago | link | parent

Now to build a high-level import system on top of this, the kind dido is looking for. I'll assume we're restricted to interned symbols.

Just before loading arc.arc, the initial symbol replacement rule is the identity function, and the initial environment contains only the builtins. Each builtin value is located in its own compilation box (no sharing!) and filed under its familiar name as an interned symbol. For instance, the + procedure is filed under the "+" symbol, with no prefixing.

Just before we go to the REPL or the main program file, we take a snapshot of the current global environment and the current symbol replacement rule.

Suppose we want (import foo) to do an unqualified import of everything in foo.arc, including the things it depends on. This will be very much like (load "foo.arc"), but foo.arc will see only the core utilities, not our additional definitions. Here are the steps:

1) Create a new global environment based on the core snapshot.

2) Generate a unique symbol prefix like "ns/foo/1-".

3) Create a new symbol replacement rule which checks whether or not the symbol exists in the core global environment. If it does, it's returned as-is. Otherwise, the prefix is attached.

4) Process each command in foo.arc as described above, using the created environment and replacement rule as context. Then come back to our original context.

5) Replace our current global environment with a function that tries the final foo.arc environment first and our preexisting environment second. (This lookup won't affect run time efficiency, since we use compilation boxes.)

6) Replace our current symbol replacement rule with a function that checks whether or not the symbol exists in the final foo.arc environment. If it does, the function defers to the final foo.arc replacement rule. Otherwise, it defers to our preexisting replacement rule. Now, if we write "bar" and foo.arc defines bar, it'll rewrite to "ns/foo/1-bar", which is part of our new environment.

If we want to do a qualified import (import-as foo Foo) instead, then step 6 is different:

6) Replace our current global environment again so that "Foo" maps to the final foo.arc symbol replacement rule. Now, if we write "Foo::bar" and foo.arc defines bar, it'll rewrite to "ns/foo/1-bar", which is part of our new environment.


Whew! I know this is too much to expect anyone to read and understand it all at once, let alone to implement all at once. ^_^

Here are some things to consider, dido, if you generally like this synthesis of ideas but want to spin it up or simplify it:

In the (import ...) mechanisms I described, we filter the symbol replacement rule by querying the environment, so this mechanism actually requires both notions of first-class namespace. If we provide some other way to filter, such letting each file build its own list of export symbols, then replacement rules could exist as the sole namespace system.

On the other hand, if we use first-class environments, we can simply bind "bar" in our namespace to a compilation box we get from foo.arc, and we don't need to fiddle with replacements like "ns/foo/1-bar" and the ssyntax issues. I think there's much more conceptual simplicity to this approach. Unfortunately, it demands the use of hygienic macros, which undermines Arc compatibility.