Re: PilCon Friday
On Sat, Nov 07, 2020 at 06:55:34AM -0600, Erik Gustafson wrote: > Another vote for Saturdays 8:00 / 16:00 UTC here > > On Sat, Nov 7, 2020, 6:14 AM Davide BERTOLOTTO > wrote: > > > Saturdays with the usual schedule sounds good for me OK, there seems some agreement on Saturdays. Let's try it! The *next* PilCon will still be according to the old schedule, thus the third Friday this month Fri 20 Nov 2020 at 16:00 UTC and then Sat 05 Dec 2020 at 8:00 UTC Sat 19 Dec 2020 at 16:00 UTC ... ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Unsubscribe
Good bye Joe Golden :-( You are now unsubscribed Unsubscribe -- Joe Golden -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Pil21 feature questions
Hi Alex, Thank you for the descriptions. Regards, Andras > On 2020. Nov 10., at 12:49, Alexander Burger 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. > > : (private) foo # Intern 'foo' in 'priv' > > : (symbols) # Search order > -> (pico) > > : (all 'priv) > -> (priv~foo) > > 'priv' is not put into the search order at all, but internally it is always > searched first. That way it will not be overridden by symbols with the same > names in 'pico', but still *new* symbols will be interned in 'pico'. > > >> - What is the purpose of the ‘~’ marker in the namespaces? > > This is only used for error checking: To check in 'symbols' that the arguments > are really namespaces, and that 'nsp' in 'nsp~foo' is OK. > > >> - What does it mean, that map functions accept atomic arguments? >> It is not required to pass lists as arguments? >> Atomic arguments are handled as 1-item lists or infinite lists with the >> same item? > > Yes, the latter. > > In pil32 and pil64 you could call > > : (mapcar * (1 2 3 4 5 6) (2 .)) > -> (2 4 6 8 10 12) > > i.e. supply an infinite list of 2's. > > Now in pil21 you can simply call > > : (mapcar * (1 2 3 4 5 6) 2) > > This is especially useful if '2' is not a constant, e.g. > > (mapcar * Lst Factor) > > In pil64 you would need to build the circular list explicitly: > > (mapcar * Lst (circ Factor)) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Pil21 feature questions
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. : (private) foo # Intern 'foo' in 'priv' : (symbols) # Search order -> (pico) : (all 'priv) -> (priv~foo) 'priv' is not put into the search order at all, but internally it is always searched first. That way it will not be overridden by symbols with the same names in 'pico', but still *new* symbols will be interned in 'pico'. > - What is the purpose of the ‘~’ marker in the namespaces? This is only used for error checking: To check in 'symbols' that the arguments are really namespaces, and that 'nsp' in 'nsp~foo' is OK. > - What does it mean, that map functions accept atomic arguments? > It is not required to pass lists as arguments? > Atomic arguments are handled as 1-item lists or infinite lists with the > same item? Yes, the latter. In pil32 and pil64 you could call : (mapcar * (1 2 3 4 5 6) (2 .)) -> (2 4 6 8 10 12) i.e. supply an infinite list of 2's. Now in pil21 you can simply call : (mapcar * (1 2 3 4 5 6) 2) This is especially useful if '2' is not a constant, e.g. (mapcar * Lst Factor) In pil64 you would need to build the circular list explicitly: (mapcar * Lst (circ Factor)) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Pil21 feature questions
Hi Alex, 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... - What is special in the ‘priv’ namespace handling? pil64 used it to store (private) symbols. - What is the purpose of the ‘~’ marker in the namespaces? - What does it mean, that map functions accept atomic arguments? It is not required to pass lists as arguments? Atomic arguments are handled as 1-item lists or infinite lists with the same item? Thank you, Andras -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
