>> Personally I am not a fan of namespaces in picolisp.
> Yes. As you know, I am neither.
at least we agree on this;-)
> However, the current implementation won't do any harm, as long as it
> is not actually used (and I won't probably use it ;-)
Why to add this feature to picolisp if it is not supposed to be used?
It doesn't make sense. Henrik is happy with his class approach anyway.
> Now, with the 'symbols' extension, there may be several global symbol
Ok, so we have now a way to refer to symbols with the same name but in
different symbol tables.
> But I wouldn't call that "solving symbol name clashes". There was never
> a clash of symbol names, because only a single internal symbol with a
> given name could ever exist in the system. Instead, the problem were
> "definition" clashes (trying to give different values or properties to a
> symbol). Henrik solved that for himself with OO techiques.
> Concerning "namespace name clashes": I can see two problems at the
> 1. renaming a symbol (with 'name'), and
> 2. importing a symbol from another namespace (with 'intern')
Renaming a symbol is not interesting. Importing maybe is, to a certain
>> One of the most important operations on namespaces should be creating
>> a local name (alias) for it.
> I don't see a way. That's what I meant when in the past I said that
> namespaces don't go well with the general principles of symbols.
> In PicoLisp, the name is an attribute of the symbol, not of the
> namespace. A symbol may have only one single name. It may be referred
> to from one or several symbol tables. An alias would require that the
> name is stored in the symbol table instead of the symbol, and then
> have the symbol hold a list of all namespaces that refer to
> it. Printing would look up the actual name in the current namespace.
You'd need to separate the concept of symbol name and name of the symbol
table. An alias I'm talking about is about making an alias for a symbol
Suppose I'm using the default symbol table 'pico'. There are also
symbol tables 'st1' and 'st2'. Symbol implementation would not have to
change. Only the reader would look up symbols in the specified symbol
An example assuming symbol tables are first class objects:
# create new empty symbol table (missing from your original example?)
(symbols 'st1 NIL)
(symbols 'st2 NIL)
(setq st1~sym1 1
(setq sym1 3)
(setq sym1 4)
(symbols 'pico) # set current namespace
(println st1~sym1 st2~sym1) # => 3 4
# create symbol table alias
(setq x st1)
(setq x~sym1 5)
(print sym1 x~sym1 st1~sym1) # => 5 5 5
Something like that.
Then Henrik's example:
> (foo.bar.blabla.abra.kadabra.func arg1 arg2)
>> (func> '+Foo.bar.blabla.abra.kadabra arg1 arg2)
(symbols (symbols 'foo~bar~blabla~abra~kadabra NIL))
(de func (arg1 arg2) ...)
(setq x foo~bar~blabla~abra~kadabra)
(x~func arg1 arg2)
Your seems to stick many possible meanings into the 'symbols' fexpr but
still doesn't cover interesting usage. For example: How can I create a
new empty symbol table? How do I refer to a symbol table without making
it the default one?
> This would be quite some overhead, destroying the "once cell per
> symbol" feature, and make things even more complicated for the
I imagine the proposed change should be at the symbol table, reader and
printer level. It should not change anything about symbols.
> Also I think that an alias would not have such very big advantages
> over writing the full specification 'myNames~Foo'.
Once you start with the symbol table idea, it does;-) Not with such a
useless name as myNames. Imagine a real world:
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. Now he has a problem;-)
Currently, without symbol tables, picolisp programmers use OS processes
and 'load' function to handle clashes like this. As an example see
This is not a problem in the world of a lone wolf developer.
However, in the scenario above, programmer E must change the sources if
the is no support for symbol table aliases.