Hi all, please note that I released a slight modification of the namespace support: The 'load' function will preserve the current namespace, even if it is changed by 'symbols' while loading a file.
The reasons can be seen best in the example from the previous discussion with Tomas: > > Programmer A develops a groundbreaking library called xml. > > Programmer B develops another groundbreaking library called xml. > > Programmer C develops a library which uses A's xml library. > > Programmer D develops a library which uses B's xml library. > > Programmer E develops an application using libraries developed by > > programmers C and D. > ... > ### File "libA.l" ### > (setq "ns" (symbols 'a 'pico)) > > (de xml (A) 'A) > > (symbols "ns") > > > ### File "libB.l" ### > (setq "ns" (symbols 'b 'pico)) > > (de xml (B) 'B) > > (symbols "ns") > > > ### File "libC.l" ### > (load "libA.l") > (setq "ns" (symbols 'c 'a)) > > (de foo (X) > (xml X) ) > > (symbols "ns") > > > ### File "libD.l" ### > (load "libB.l") > (setq "ns" (symbols 'd 'b)) > > (de foo (X) > (xml X) ) > > (symbols "ns") > > > ### Program E ### > (load "libC.l" "libD.l") > > (println (c~foo) (d~foo)) > > Output: > A B As you see, this ends up with saving the current namespace in each module (source file), by keeping it in a transient symbol "ns", defining the module's contents, and then restoring it with (symbols "ns"). I think this is necessary, because otherwise I got a surprising behavior. If I simply did ### File "libA.l" ### (symbols 'a 'pico) (de xml (A) 'A) ### File "libB.l" ### (symbols 'b 'pico) (de xml (B) 'B) ### File "libC.l" ### (load "libA.l") (symbols 'c 'a) (de foo (X) (xml X)) ### File "libD.l" ### (load "libB.l") (symbols 'd 'b) (de foo (X) (xml X)) then back in the the main program (load "libC.l" "libD.l") (println (c~foo) (d~foo)) I got an error: "c -- Bad symbol namespace" Why that? Answer: After loading "libC.l", and then "libD.l", the current namespace is on 'd'. The namespace 'c', however, was defined while namespace 'a' was current (after loading "libA.l" in "libC.l"), so 'c' is neither in 'pico' nor in 'b' (which was then used to derive 'd'). 'c' is accessible only via 'a'. 'foo' could now be accessed as a~c~foo, because 'a' was inherited from 'pico' -> 'b' -> 'd' ('b' was created later in 'pico' than 'a'). Confusing, isn't it? It is desirable to have 'c' accessible from 'pico' (or whatever namespace was current when the main program loaded the two libraries), so that c~foo and d~foo are valid. The only clean way I can see is to save the currently active namespace at the beginning of a module. For that reason I wrote in the initial exampes, at the beginning of each module (setq "ns" (symbols 'newLib 'oldLib)) and at the end (symbols "ns") This looks ugly. And as it is indeed needed for _each_ module, we may as well hard-code it into the 'load' function. With that, the situation suddenly becomes very simple and clear. A source file (or several nested source files) gets its own namespace simply by calling (symbols 'newLib 'oldLib) at the beginning, possibly after loading other required sources. Here, 'oldLib' can be anything, it must not necessarily be the current namespace. It should be whatever this module needs, i.e. where it builds upon. However, 'newLib' will be automatically created in the current namespace, i.e. the namespace of the caller. As 'symbols' sets the new current namespace to 'newLib', all newly created symbols will go into that namespace. (Caution! You should be aware that all this namespace stuff operates strictly on the symbol level. It is not concerned about values, definitions, properties etc. of the involved symbols. Note the term "created symbols" in the previous paragraph. Especially, if a symbol already exists in 'oldLib', it will stay there, of course, and possible definitions for that symbol will be visible there too). When 'load' finishes, the current namespace is automatically reset to the previous one. Now the new symbols in 'newLib' can be either accessed via the '~' read macro newLib~foo or by switching completely to the new namespace with (symbols 'newLib) and further referring to it simply as 'foo'. Side note: The above tests print the warning # d redefined This is correct, because 'd' is a debugger function. In practice, it would be better to select non-conflicting names for the namespaces. Besides this, the examples work (just the 'd' function is gone ;-) Cheers, - Alex -- UNSUBSCRIBE: mailto:email@example.com?subject=Unsubscribe