My example implied that +Kadabra is a sublass of a sublcass and so on up to
+Foo.


On Tue, Sep 20, 2011 at 12:56 AM, Tomas Hlavaty <t...@logand.com> wrote:

> Hi Alex,
>
> >> 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
> > tables
>
> 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
> > moment:
> >
> >    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
> point.
>
> >> 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
> table.
>
> 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
> table.
>
> 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
>         st2~sym1 2)
>
>   (symbols 'st1)
>   (setq sym1 3)
>
>   (symbols 'st2)
>   (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)
>
> Library code:
>
>  (symbols (symbols 'foo~bar~blabla~abra~kadabra NIL))
>
>  (de func (arg1 arg2) ...)
>
> App code:
>
>  (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
> > programmer.
>
> 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
>
>   lib/xm.l
>   lib/xml.l
>
> 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.
>
> Cheers,
>
> Tomas
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Reply via email to