Hi Tomas,
> Personally I am not a fan of namespaces in picolisp.
Yes. As you know, I am neither.
However, the current implementation won't do any harm, as long as it is
not actually used (and I won't probably use it ;-)
It is a simple extension of the general principles underlying PicoLisp
symbols.
Until now, a symbol was either interned or not interned into the global
symbol table (if we ignore external symbols for the moment, and regard
transient symbols as a special way of implicit interning / uninterning a
symbol).
Now, with the 'symbols' extension, there may be several global symbol
tables, with one of them active at a given time. A new symbol table is a
copy of an existing one. Thus, a symbol may be either non-interned, or
interned in one or several symbol tables.
It is all about symbols, not about names. For that reason, I avoided the
term "namespace" for the new function, and called it "symbols".
> However, once there is support for namespaces, as Christian points out,
> there are other operations that should be supported. It seems to me
> that your suggested implementation solves the problem of symbol name
> clashes, but introduces a new problem of namespace name clashes. Do I
> read that right?
Probably. Fact is, now we may have two or more _interned_ symbols with
the same name, as long as they are interned into 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
moment:
1. renaming a symbol (with 'name'), and
2. importing a symbol from another namespace (with 'intern')
Renaming was (and is) allowed only for uninterned symbols. To rename an
interned symbol, you must first unintern it (with 'zap'), assign a new
name (with 'name') and then intern it again (with 'intern'). The problem
now is that the programmer is in charge of uninterning the symbol from
all symbol tables, which might not be feasible, and is also probably not
what was intended with the renaming in the first place.
Importing symbol from another namespace can be done with
(intern 'myNames~Foo)
-> Foo
This will make the symbol 'Foo' from 'myNames' available as an internal
symbol in the current namespace.
However, the pitfall is that if 'Foo' already existed in the current
namespace, 'intern' will return _that_ symbol - and not the symbol with
the same name in 'myNames'. Thus, the import should actually be
something like
(unless (== 'myNames~Foo (intern 'myNames~Foo))
(msg 'Foo " is already interned") )
> One of the most important operations on namespaces
> should be creating a local name (alias) for it. Common Lisp didn't get
> this right, for example, so it would be great if picolisp avoided that
> flaw.
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.
This would be quite some overhead, destroying the "once cell per symbol"
feature, and make things even more complicated for the programmer.
Also I think that an alias would not have such very big advantages over
writing the full specification 'myNames~Foo'.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
