> (map * Lst (circ Factor)) *`[let [Circ [1 .]]* * '[let [`Circ Factor]* * (mapcar * Lst `Circ)) ] ]*
On Tue, Nov 10, 2020, 13:57 Andras Pahi <pa...@t-online.hu> wrote: > Hi Alex, > > Thank you for the descriptions. > > Regards, > Andras > > > On 2020. Nov 10., at 12:49, Alexander Burger <a...@software-lab.de> > wrote: > > > > Hi Andras, > > > >> I would like to ask some questions on Pil21 features. > >> It is enough if you points to some examples where I could dig into the > >> details... > > > > These are indeed very good questions! Thanks that you ask, they need to > be > > clarified. > > > > > >> - What is special in the ‘priv’ namespace handling? > >> pil64 used it to store (private) symbols. > > > > I noticed that the way pil64 implemented the 'private' function was not > good. > > > > It created a normal namespace 'priv' on-the-fly, interned the given > symbols into > > that namespace, and then put 'priv' as the *second* namespace in the > search > > order: > > > > : (private) foo # Intern 'foo' in 'priv' > > > > : (symbols) # Search order > > -> (pico priv) > > > > So now 'foo' is indeed private. The problem is that *if' another symbol > named > > "foo" exists in 'pico', it overshadoes the 'foo' in 'priv', and this is > not what > > is expected for a private symbol. > > > > > > Pil21 implements a special handling for 'priv'. Now 'priv' is part of the > > interpreter core, and behaves a little different from normal namespaces
