Hi Chrostophe and Alex

Thank you very much for your advice....It is very timely.

I'm only too aware of the dangers of using setq, having been bitten a few
times now by interference between functions in my whole program.

I'm tending to develop functions in isolation so I can watch them like a
hawk. setq isn't a problem in such isolation and the ONLY reason I'm  using
setq is my lack of adeptness reconciling the the scoping inherent in "let"
with the bracketing I THINK I need to obtain the desired flow of control

(let Some_sym.......
      Some_sym is seen anywhere up to the closing bracket above  ---)

but then I seem to want to access Some_sym beyond the closing bracket
SEEMINGLY dictated by the flow of control.

Having just sorted out my first object's logic and layout now is probably a
good time to go back and replace all of my setq's with let's. If either of
you have any advice on how best to use "let"...I'd certainly welcome it
i.e. is it just a case of

(let A 1 B2

write your program as usual here safe in the knowledge that you have access
to A and B


I tried this but don't seem to get B

: (let A 1 B 2
(prinl A)
(prinl B)

I would like to crack this so any advice re how to correctly use "let"
would be very welcome and appreciated. BTW....PL's object system is a
pleasure to use. Thank you for it!

Best Regards

On 28 January 2017 at 19:13, Alexander Burger <a...@software-lab.de> wrote:

> Hi Christophe,
> > > (de fltr (Buf Ln)
> > >    (setq New_buf (mapcar '((Ele) (pack (tail (- (length Ln)) (chop
> Ele))))
> > >       (filter '((Ele) (pre? Ln Ele)) Buf))))
> >
> > I'm not an expert, I just want to warn and maybe be confirmed.
> > As Alex said recently, PicoLisp programs should rarely use setq.
> Indeed! When I saw the above definition, I was ready to say something
> about it.
> But then I understood that Dean obviously just extracted a sample from some
> other code he is working on, and that the 'setq' might be the remains of
> experimentation.
> > I'd add (please confirm):
> > 1) especially in function definitions, as
> > 2) it creates/modifies like «global variables», which many consider
> > bad practice.
> Yes. At least - if it is really necessary - is should be named '*New_buf'
> to
> mark it clearly as a global.
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to