Re: (NIL) vs Nothing

[dean]

Thank you for your further explanation


On 4 February 2017 at 08:29, Alexander Burger  wrote:

> On Fri, Feb 03, 2017 at 10:04:02PM +0100, pd wrote:
> > The reason for this difference is let behaviour:  let binds a symbol to a
> > value *inside* let expression but first saves values of binding symbols
> and
> > once evaluated the expression it restores previous symbols values saved

Re: (NIL) vs Nothing

[Alexander Burger]

On Fri, Feb 03, 2017 at 10:04:02PM +0100, pd wrote:
> The reason for this difference is let behaviour:  let binds a symbol to a
> value *inside* let expression but first saves values of binding symbols and
> once evaluated the expression it restores previous symbols values saved.
> ...

Your explanations are correct. Thanks!


> As picolisp seem not to have a let* like in classical lisp I assume let
> bindings are done in parallel as traditionally let behaves in classical
> lisp

No, it is the opposite: The PicoLisp 'let' evaluates and binds the values one
after the other, not in parallel, so it behaves like 'let*' in Common Lisp:

   : (let (A 3  B (+ A 4))  # B depends on A
  (cons A B) )
   -> (3 . 7)

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: (NIL) vs Nothing

[dean]

Thank you very much for the explanation.

On 3 February 2017 at 21:04, pd  wrote:

> The reason for this difference is let behaviour:  let binds a symbol to a
> value *inside* let expression but first saves values of binding symbols and
> once evaluated the expression it restores previous symbols values saved.
>
> So, when you wrap a expression in a let binding you are protecting the
> symbols values for further modification, each internal wrapping with let
> gives you a layer of protection.
>
> In first version you protect the expression in a let wrapping, the
> expression (the let body) may change symbols in any way because after being
> evaluated (let's say when exiting let function) the symbol value of symbols
> bound by let will be restored to previus value. But *inside* the clause
> changes happen!
>
> : (let X 0# let binds symbol X to 0 *inside* let
> expression (the following line)
> (for Y 3 (inc 'X) (prinl X))  # in this let expression every change
> to symbol X takes effect, in particular incrementing it
>   )   # after execution of let expression
> binding symbols are restored to saved value (in this case without more
> information it shoud be NIL)
>
> But in second version you add an extra protection layer to the expression
> by wrapping it in a let binding, as always expressions may change symbols
> inside let expression but now they are protected by a internal let layer
> which "hides changing effects"
>
> : (let X 0  # let binds symbol X to 0 *inside* let expression
> (the following lines)
>(for Y 3
>   (let X (inc 'X)   # but now you have an extra let protecction layer
> which binds X thus protecting it for changes made in inner let expression
> by saving current X value (0)
> (prinl X)   # this is inner let expression, prints the value
> of inner X binding (which is always 1 because is always incrementing 0 by 1
> as we will see)
>   ) # at this point let restores value of symbol X to
> previous value , which is 0 as set by outer let binding
>)# so each step of for loop symbol X has value 0
> (because is setted by outer let and restored by inner let) and thus get
> incremeted to 1
>   )
>
> So as you can see let is used to isolate actions without affecting current
> symbol values, you can think of it as "hiding actions"  You can think about
> it in terms of lambda applications which may be easier to understand (if
> you're interested let me know ;-)
>
> As picolisp seem not to have a let* like in classical lisp I assume let
> bindings are done in parallel as traditionally let behaves in classical
> lisp, sure Alex can state it clearly
>
>
> On Thu, Feb 2, 2017 at 7:20 PM, dean  wrote:
>
>> Just to illustrate what I meant...
>> : (let X 0
>>(for Y 3
>>   (let X (inc 'X) (prinl X
>> 1
>> 1
>> 1
>> -> 1
>>
>> On 2 February 2017 at 18:16, dean  wrote:
>>
>>> Thank you very much for the adviceI've just used that and it's
>>> worked a treat
>>>
>>> : (let X 0
>>>   (for Y 3
>>>  (inc 'X) (prinl X)))
>>> 1
>>> 2
>>> 3
>>> -> 3
>>>
>>
>
> --
> Andrés
>
> *~ La mejor manera de librarse de la tentación es caer en ella**. ~ Oscar
> Wilde* ~
>

Re: (NIL) vs Nothing

[pd]

The reason for this difference is let behaviour:  let binds a symbol to a
value *inside* let expression but first saves values of binding symbols and
once evaluated the expression it restores previous symbols values saved.

So, when you wrap a expression in a let binding you are protecting the
symbols values for further modification, each internal wrapping with let
gives you a layer of protection.

In first version you protect the expression in a let wrapping, the
expression (the let body) may change symbols in any way because after being
evaluated (let's say when exiting let function) the symbol value of symbols
bound by let will be restored to previus value. But *inside* the clause
changes happen!

: (let X 0# let binds symbol X to 0 *inside* let
expression (the following line)
(for Y 3 (inc 'X) (prinl X))  # in this let expression every change to
symbol X takes effect, in particular incrementing it
  )   # after execution of let expression
binding symbols are restored to saved value (in this case without more
information it shoud be NIL)

But in second version you add an extra protection layer to the expression
by wrapping it in a let binding, as always expressions may change symbols
inside let expression but now they are protected by a internal let layer
which "hides changing effects"

: (let X 0  # let binds symbol X to 0 *inside* let expression
(the following lines)
   (for Y 3
  (let X (inc 'X)   # but now you have an extra let protecction layer
which binds X thus protecting it for changes made in inner let expression
by saving current X value (0)
(prinl X)   # this is inner let expression, prints the value of
inner X binding (which is always 1 because is always incrementing 0 by 1 as
we will see)
  ) # at this point let restores value of symbol X to
previous value , which is 0 as set by outer let binding
   )# so each step of for loop symbol X has value 0
(because is setted by outer let and restored by inner let) and thus get
incremeted to 1
  )

So as you can see let is used to isolate actions without affecting current
symbol values, you can think of it as "hiding actions"  You can think about
it in terms of lambda applications which may be easier to understand (if
you're interested let me know ;-)

As picolisp seem not to have a let* like in classical lisp I assume let
bindings are done in parallel as traditionally let behaves in classical
lisp, sure Alex can state it clearly


On Thu, Feb 2, 2017 at 7:20 PM, dean  wrote:

> Just to illustrate what I meant...
> : (let X 0
>(for Y 3
>   (let X (inc 'X) (prinl X
> 1
> 1
> 1
> -> 1
>
> On 2 February 2017 at 18:16, dean  wrote:
>
>> Thank you very much for the adviceI've just used that and it's worked
>> a treat
>>
>> : (let X 0
>>   (for Y 3
>>  (inc 'X) (prinl X)))
>> 1
>> 2
>> 3
>> -> 3
>>
>

-- 
Andrés

*~ La mejor manera de librarse de la tentación es caer en ella**. ~ Oscar
Wilde* ~

Re: (NIL) vs Nothing

[dean]

Just to illustrate what I meant...
: (let X 0
   (for Y 3
  (let X (inc 'X) (prinl X
1
1
1
-> 1

On 2 February 2017 at 18:16, dean  wrote:

> Thank you very much for the adviceI've just used that and it's worked
> a treat
>
> : (let X 0
>   (for Y 3
>  (inc 'X) (prinl X)))
> 1
> 2
> 3
> -> 3
> I did try my first example with lets instead of setqs but the second let
> kept looking at the first let value precluding any
> incrementation...ELIMINATING the second let and using just inc inc as you
> advised removes the problem by allowing just one let at the top which
> works great.
>
> Perhaps inc contains an inc somewhere otherwise how does X actually get
> changed but if it does...it doesn't look to be in a place that interferes
> with the first let.
>
> Irrespective...you've provided a very elegant solution to my problem and I
> thank you for it!
>
> On 2 February 2017 at 17:24, pd  wrote:
>
>> I think this is not the use you intent
>>
>> In *my* opinion:
>>
>> On Thu, Feb 2, 2017 at 3:44 PM, dean > > wrote:
>>
>>>
>>>(setq Ln_no 0)
>>>(in Epic_txt_fl_pth
>>>   (until (eof)
>>>  (setq Ln_no (inc 'Ln_no) )
>>>
>>
>> this is redudant since you're simply incrementing the value of a global
>> symbol, simply write:   (inc 'Ln_no)
>>
>>
>>>  (prog
>>> ​
>>>
>>
>> As a general not too exact rule setq creates global value while let
>> creates a local value
>>
>> More exactly setq (and set) binds a symbol to a value in the "global
>> context" while let binds a symbol to a value only inside the let expression
>>
>>
>

Re: (NIL) vs Nothing

[dean]

Thank you very much for the adviceI've just used that and it's worked a
treat

: (let X 0
  (for Y 3
 (inc 'X) (prinl X)))
1
2
3
-> 3
I did try my first example with lets instead of setqs but the second let
kept looking at the first let value precluding any
incrementation...ELIMINATING the second let and using just inc inc as you
advised removes the problem by allowing just one let at the top which
works great.

Perhaps inc contains an inc somewhere otherwise how does X actually get
changed but if it does...it doesn't look to be in a place that interferes
with the first let.

Irrespective...you've provided a very elegant solution to my problem and I
thank you for it!

On 2 February 2017 at 17:24, pd  wrote:

> I think this is not the use you intent
>
> In *my* opinion:
>
> On Thu, Feb 2, 2017 at 3:44 PM, dean  > wrote:
>
>>
>>(setq Ln_no 0)
>>(in Epic_txt_fl_pth
>>   (until (eof)
>>  (setq Ln_no (inc 'Ln_no) )
>>
>
> this is redudant since you're simply incrementing the value of a global
> symbol, simply write:   (inc 'Ln_no)
>
>
>>  (prog
>> ​
>>
>
> As a general not too exact rule setq creates global value while let
> creates a local value
>
> More exactly setq (and set) binds a symbol to a value in the "global
> context" while let binds a symbol to a value only inside the let expression
>
>

Re: (NIL) vs Nothing

[pd]

I think this is not the use you intent

In *my* opinion:

On Thu, Feb 2, 2017 at 3:44 PM, dean  wrote:

>
>(setq Ln_no 0)
>(in Epic_txt_fl_pth
>   (until (eof)
>  (setq Ln_no (inc 'Ln_no) )
>

this is redudant since you're simply incrementing the value of a global
symbol, simply write:   (inc 'Ln_no)


>  (prog
> ​
>

As a general not too exact rule setq creates global value while let creates
a local value

More exactly setq (and set) binds a symbol to a value in the "global
context" while let binds a symbol to a value only inside the let expression

Re: (NIL) vs Nothing

[dean]

Thank you for your insight that contradicts and clarifies numerous of my
misconceptions.
That's exactly what I needed.
Best Regards
Dean


On 1 February 2017 at 08:20, Alexander Burger  wrote:

> He Dean,
>
> > I've "proved" that a let statement's result is visible ANYWHERE within
> it's
> > bounding parens but not outside of them and
>
> That's right. However, the term "a let statement's result" means something
> different.
>
>(let A 3
>   (* A 4) )
>
> This 'let' statement has the *result* 12. The symbol 'A' is *bound" to the
> result of evaluating the expression '3'. And this binding is valid
> throughout
> the body of the 'let'.
>
>
> > I was hoping to define the scope of X locally by wrapping the lot with
> > (let X some_dummy_value
>
> 'let' does not define the scope of 'X'. 'X' is an internal symbol which has
> always global scope ("scope" means "visibility"). What 'let' does is to
> set up
> the binding, which means saving the current value, assigning a new one, and
> restoring the old value when the 'let' is done.
>
>
> > but binding X to some dummy value casts that value in
> stone...invalidating
>
> This is not true. The value can be changed
>
>(let A 3
>   (setq A (inc (* A 4)))
>   ...
>   A )
>
> This should return 13.
>
>
> Note that 'let' is just a shorthand for 'use' + 'setq':
>
>(let A 3
>   ...
>
> is the same as
>
>(use A
>   (setq A 3)
>   ...
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: (NIL) vs Nothing

[dean]

After playing around with some test programs ...I think I've got most of
that now.
I've "proved" that a let statement's result is visible ANYWHERE within it's
bounding parens but not outside of them and

If we have
(do something to X)
(do something to Y)
(do something to X again)

I was hoping to define the scope of X locally by wrapping the lot with
(let X some_dummy_value

   the above 3 statements

)

but binding X to some dummy value casts that value in stone...invalidating
the thing altogether because you only get one go at assigning the value so
it's got to be the "proper" value which you might not know at new contrived
level I was hoping to introduce.

Is that right?

 I didn't know about if (: some_member)or that I could just end a
function/method with e.g.

(if (gt0 (: first_ln_no))
   (: first_ln_no)
   Ln_no )

but really like this short and to the point syntax.

Again...thank you very muchI feel I've learnt a lot today.
Best Regards
Dean






On 31 January 2017 at 19:30, dean  wrote:

> BTW
> > This *might* be what you need. I can't test it.
> Yes...it works perfectly!
>
> On 31 January 2017 at 19:15, dean  wrote:
>
>> > This *might* be what you need. I can't test it.
>> That's fine.
>> Your comments are EXTREMELY helpful because as you correctly note I am
>> struggling with this.
>> I still don't understand some of things you mention so please bear with
>> me and I'll try narrow down the source of my misunderstanding.
>> Thank you for your help and example.
>> They are very much appreciated.
>> Best Regards
>> Dean
>>
>>
>> On 31 January 2017 at 18:31, Alexander Burger 
>> wrote:
>>
>>> On Tue, Jan 31, 2017 at 07:14:57PM +0100, Alexander Burger wrote:
>>> > The only place where it is good is the line (setq Ln (pack " " Ln)).
>>> For the
>>> > rest all 'setq's can be simply omitted if you fix the conditional flow.
>>> >
>>> > Try it! :)
>>>
>>> OK, could not resist ;)
>>>
>>> This *might* be what you need. I can't test it.
>>>
>>>(dm ln_completes> (Ln Ln_no)
>>>   (if (gt0 (: first_ln_no))
>>>  (setq Ln (pack " " Ln)) )
>>>   (=: buf (or (: new_buf) (: hdngs)))
>>>   (if (member Ln (: buf))
>>>  (prog1
>>> (if (gt0 (: first_ln_no))
>>>(: first_ln_no)
>>>Ln_no )
>>> (reset> This) )
>>>  # not a member
>>>  (=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
>>>  (if (: new_buf)
>>> (if (=0 (: first_ln_no))
>>>(=: first_ln_no Ln_no) )
>>> (reset> This) )
>>>  0 ) )
>>>
>>> ♪♫ Alex
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>
>>
>

Re: (NIL) vs Nothing

[dean]

> This *might* be what you need. I can't test it.
That's fine.
Your comments are EXTREMELY helpful because as you correctly note I am
struggling with this.
I still don't understand some of things you mention so please bear with me
and I'll try narrow down the source of my misunderstanding.
Thank you for your help and example.
They are very much appreciated.
Best Regards
Dean


On 31 January 2017 at 18:31, Alexander Burger  wrote:

> On Tue, Jan 31, 2017 at 07:14:57PM +0100, Alexander Burger wrote:
> > The only place where it is good is the line (setq Ln (pack " " Ln)). For
> the
> > rest all 'setq's can be simply omitted if you fix the conditional flow.
> >
> > Try it! :)
>
> OK, could not resist ;)
>
> This *might* be what you need. I can't test it.
>
>(dm ln_completes> (Ln Ln_no)
>   (if (gt0 (: first_ln_no))
>  (setq Ln (pack " " Ln)) )
>   (=: buf (or (: new_buf) (: hdngs)))
>   (if (member Ln (: buf))
>  (prog1
> (if (gt0 (: first_ln_no))
>(: first_ln_no)
>Ln_no )
> (reset> This) )
>  # not a member
>  (=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
>  (if (: new_buf)
> (if (=0 (: first_ln_no))
>(=: first_ln_no Ln_no) )
> (reset> This) )
>  0 ) )
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: (NIL) vs Nothing

[Alexander Burger]

On Tue, Jan 31, 2017 at 07:14:57PM +0100, Alexander Burger wrote:
> The only place where it is good is the line (setq Ln (pack " " Ln)). For the
> rest all 'setq's can be simply omitted if you fix the conditional flow.
> 
> Try it! :)

OK, could not resist ;)

This *might* be what you need. I can't test it.

   (dm ln_completes> (Ln Ln_no)
  (if (gt0 (: first_ln_no))
 (setq Ln (pack " " Ln)) )
  (=: buf (or (: new_buf) (: hdngs)))
  (if (member Ln (: buf))
 (prog1
(if (gt0 (: first_ln_no))
   (: first_ln_no)
   Ln_no )
(reset> This) )
 # not a member
 (=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
 (if (: new_buf)
(if (=0 (: first_ln_no))
   (=: first_ln_no Ln_no) )
(reset> This) )
 0 ) )

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: (NIL) vs Nothing

[Alexander Burger]

Hi Dean,

I see a lot of confusion about 'let' and perhaps also 'setq'.

I don't know how to better explain it as it is already done in the function
references. So I just put a few comments here; please try to understand how
exactly these functions work!


>(dm ln_completes> (Ln Ln_no)
>   (let (Ln Ln Res 0)

This "Ln Ln" is a no-op. The variable 'Ln' is already bound as a parameter and
thus is already local. Instead, just do

(let Res 0


>  (if (gt0 (: first_ln_no))
> (let Ln (pack " " Ln)))

This has no effect. You bind 'Ln' again, to the result of the 'pack', but this
value is discarded because the body of the 'let' is empty.


>  (if (<> (: new_buf) NIL)

You never need to compare to NIL! Instead do

   (if (: new_buf)


> (=: buf (: new_buf))
> (=: buf (: hdngs)))
>  (if (member Ln (: buf))
> (prog
>(if (gt0 (: first_ln_no))
>   (let Res (: first_ln_no))
>   (let Res Ln_no))

Again, two empty 'lets' which have no effect at all.


>(reset> This)
>(let Res Res))

Same


> (prog #not a member
>(=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
>(if (<> (: new_buf) NIL)

Again as above


>   (if (=0 (: first_ln_no))
>  (=: first_ln_no Ln_no))
>   (reset> This))
>(let Res 0)

No effect again, so the result is NIL (= the return value of empty 'let's).


> Here's the original "setq" method
>
>(dm ln_completes> (Ln Ln_no)
>   (if (gt0 (: first_ln_no))
>  (setq Ln (pack " " Ln)))
>   (if (<> (: new_buf) NIL)
>  (=: buf (: new_buf))
>  (=: buf (: hdngs)))
>   (if (member Ln (: buf))
>  (prog
> (if (gt0 (: first_ln_no))
>(setq Res (: first_ln_no))
>(setq Res Ln_no))
> (reset> This)
> (setq Res Res))
>  (prog #not a member
> (=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
> (if (<> (: new_buf) NIL)
>(if (=0 (: first_ln_no))
>   (=: first_ln_no Ln_no))
>(reset> This))
> (setq Res 0

This has the same issues with the comparison with NIL. Besides this, it writes
to the free variable 'Res', which might destroy its value in other functions.

I don't know why you are so obsessed with 'setq' ;)

The only place where it is good is the line (setq Ln (pack " " Ln)). For the
rest all 'setq's can be simply omitted if you fix the conditional flow.

Try it! :)

If you e.g. want to return 0 at the end, why don't you just write 0 instead of
(setq Res 0), assigning the value to a variable?

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: (NIL) vs Nothing

[dean]

Here's the original "setq" method

  (dm ln_completes> (Ln Ln_no)
 (if (gt0 (: first_ln_no))
(setq Ln (pack " " Ln)))
 (if (<> (: new_buf) NIL)
(=: buf (: new_buf))
(=: buf (: hdngs)))
 (if (member Ln (: buf))
(prog
   (if (gt0 (: first_ln_no))
  (setq Res (: first_ln_no))
  (setq Res Ln_no))
   (reset> This)
   (setq Res Res))
(prog #not a member
   (=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
   (if (<> (: new_buf) NIL)
  (if (=0 (: first_ln_no))
 (=: first_ln_no Ln_no))
  (reset> This))
   (setq Res 0

On 31 January 2017 at 16:35, dean  wrote:

> Any help advising how I should restructure the parens in order to replace
> setq with let would really help me to understand how to do it.
> Thank you in anticipation and sorry if this is a really easy thing to do.
>
> On 31 January 2017 at 16:32, dean  wrote:
>
>> I've inadvertently pressed some send key combo again...
>>
>> simple use of let is fine e.g.
>> (let X 3
>>do what ever you want to do with X here without much change of hierachy
>> )
>>
>> Ln doesn't fit this usage pattern and to "let" it be something at the top
>> seems somewhat artificial because there's an if statement deciding whether
>> to change it's supplied value or not.
>>
>>
>>
>> On 31 January 2017 at 16:29, dean  wrote:
>>
>>> Oops acccidentally sent before I finished...Sorry!
>>>
>>> I was going to say the examples I've seen tend to be
>>> (let X 3
>>>
>>>
>>>
>>>
>>>
>>>(dm ln_completes> (Ln Ln_no)
>>>   (let (Ln Ln Res 0)
>>>  (if (gt0 (: first_ln_no))
>>> (let Ln (pack " " Ln)))
>>>  (if (<> (: new_buf) NIL)
>>> (=: buf (: new_buf))
>>> (=: buf (: hdngs)))
>>>  (if (member Ln (: buf))
>>> (prog
>>>(if (gt0 (: first_ln_no))
>>>   (let Res (: first_ln_no))
>>>   (let Res Ln_no))
>>>(reset> This)
>>>(let Res Res))
>>> (prog #not a member
>>>(=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
>>>(if (<> (: new_buf) NIL)
>>>   (if (=0 (: first_ln_no))
>>>  (=: first_ln_no Ln_no))
>>>   (reset> This))
>>>(let Res 0)
>>>
>>> On 31 January 2017 at 16:27, dean  wrote:
>>>
 Each one of the "let"s in the following method WAS a setq. All I did
 was wrap the existing body with parens and assign Ln and Res with "let" but
 it doesn't work. The examples I've seen tend to be like this...
 (let X 3

 )




 )


 On 30 January 2017 at 16:19, dean  wrote:

> Hi Alex
> Yes that worked great preceded by a testi.e. whizzing through all
> file lines in the input file until almost the 4000th which triggered
> reporting on the method of interests's input and output. Thank you very
> much for the advice.
> Best Regards
> Dean
>
> On 30 January 2017 at 11:07, Alexander Burger 
> wrote:
>
>> Hi Dean,
>>
>> > trace operates in debug mode but again am not exactly sure how to
>> ensure
>> > that I am in debug mode on a method (rather than a function which
>> is just
>> > (debug 'Fn) at that point.
>> > I have tried but get can't trace.
>>
>> While (trace 'foo) traces a function, (trace 'meth> '+Class) traces a
>> method.
>>
>> ♪♫ Alex
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
>

>>>
>>
>

Re: (NIL) vs Nothing

[dean]

I've inadvertently pressed some send key combo again...

simple use of let is fine e.g.
(let X 3
   do what ever you want to do with X here without much change of hierachy
)

Ln doesn't fit this usage pattern and to "let" it be something at the top
seems somewhat artificial because there's an if statement deciding whether
to change it's supplied value or not.



On 31 January 2017 at 16:29, dean  wrote:

> Oops acccidentally sent before I finished...Sorry!
>
> I was going to say the examples I've seen tend to be
> (let X 3
>
>
>
>
>
>(dm ln_completes> (Ln Ln_no)
>   (let (Ln Ln Res 0)
>  (if (gt0 (: first_ln_no))
> (let Ln (pack " " Ln)))
>  (if (<> (: new_buf) NIL)
> (=: buf (: new_buf))
> (=: buf (: hdngs)))
>  (if (member Ln (: buf))
> (prog
>(if (gt0 (: first_ln_no))
>   (let Res (: first_ln_no))
>   (let Res Ln_no))
>(reset> This)
>(let Res Res))
> (prog #not a member
>(=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
>(if (<> (: new_buf) NIL)
>   (if (=0 (: first_ln_no))
>  (=: first_ln_no Ln_no))
>   (reset> This))
>(let Res 0)
>
> On 31 January 2017 at 16:27, dean  wrote:
>
>> Each one of the "let"s in the following method WAS a setq. All I did was
>> wrap the existing body with parens and assign Ln and Res with "let" but it
>> doesn't work. The examples I've seen tend to be like this...
>> (let X 3
>>
>> )
>>
>>
>>
>>
>> )
>>
>>
>> On 30 January 2017 at 16:19, dean  wrote:
>>
>>> Hi Alex
>>> Yes that worked great preceded by a testi.e. whizzing through all
>>> file lines in the input file until almost the 4000th which triggered
>>> reporting on the method of interests's input and output. Thank you very
>>> much for the advice.
>>> Best Regards
>>> Dean
>>>
>>> On 30 January 2017 at 11:07, Alexander Burger 
>>> wrote:
>>>
 Hi Dean,

 > trace operates in debug mode but again am not exactly sure how to
 ensure
 > that I am in debug mode on a method (rather than a function which is
 just
 > (debug 'Fn) at that point.
 > I have tried but get can't trace.

 While (trace 'foo) traces a function, (trace 'meth> '+Class) traces a
 method.

 ♪♫ Alex
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

>>>
>>>
>>
>

Re: (NIL) vs Nothing

[dean]

Any help advising how I should restructure the parens in order to replace
setq with let would really help me to understand how to do it.
Thank you in anticipation and sorry if this is a really easy thing to do.

On 31 January 2017 at 16:32, dean  wrote:

> I've inadvertently pressed some send key combo again...
>
> simple use of let is fine e.g.
> (let X 3
>do what ever you want to do with X here without much change of hierachy
> )
>
> Ln doesn't fit this usage pattern and to "let" it be something at the top
> seems somewhat artificial because there's an if statement deciding whether
> to change it's supplied value or not.
>
>
>
> On 31 January 2017 at 16:29, dean  wrote:
>
>> Oops acccidentally sent before I finished...Sorry!
>>
>> I was going to say the examples I've seen tend to be
>> (let X 3
>>
>>
>>
>>
>>
>>(dm ln_completes> (Ln Ln_no)
>>   (let (Ln Ln Res 0)
>>  (if (gt0 (: first_ln_no))
>> (let Ln (pack " " Ln)))
>>  (if (<> (: new_buf) NIL)
>> (=: buf (: new_buf))
>> (=: buf (: hdngs)))
>>  (if (member Ln (: buf))
>> (prog
>>(if (gt0 (: first_ln_no))
>>   (let Res (: first_ln_no))
>>   (let Res Ln_no))
>>(reset> This)
>>(let Res Res))
>> (prog #not a member
>>(=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
>>(if (<> (: new_buf) NIL)
>>   (if (=0 (: first_ln_no))
>>  (=: first_ln_no Ln_no))
>>   (reset> This))
>>(let Res 0)
>>
>> On 31 January 2017 at 16:27, dean  wrote:
>>
>>> Each one of the "let"s in the following method WAS a setq. All I did was
>>> wrap the existing body with parens and assign Ln and Res with "let" but it
>>> doesn't work. The examples I've seen tend to be like this...
>>> (let X 3
>>>
>>> )
>>>
>>>
>>>
>>>
>>> )
>>>
>>>
>>> On 30 January 2017 at 16:19, dean  wrote:
>>>
 Hi Alex
 Yes that worked great preceded by a testi.e. whizzing through all
 file lines in the input file until almost the 4000th which triggered
 reporting on the method of interests's input and output. Thank you very
 much for the advice.
 Best Regards
 Dean

 On 30 January 2017 at 11:07, Alexander Burger 
 wrote:

> Hi Dean,
>
> > trace operates in debug mode but again am not exactly sure how to
> ensure
> > that I am in debug mode on a method (rather than a function which is
> just
> > (debug 'Fn) at that point.
> > I have tried but get can't trace.
>
> While (trace 'foo) traces a function, (trace 'meth> '+Class) traces a
> method.
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


>>>
>>
>

Re: (NIL) vs Nothing

[dean]

Oops acccidentally sent before I finished...Sorry!

I was going to say the examples I've seen tend to be
(let X 3





   (dm ln_completes> (Ln Ln_no)
  (let (Ln Ln Res 0)
 (if (gt0 (: first_ln_no))
(let Ln (pack " " Ln)))
 (if (<> (: new_buf) NIL)
(=: buf (: new_buf))
(=: buf (: hdngs)))
 (if (member Ln (: buf))
(prog
   (if (gt0 (: first_ln_no))
  (let Res (: first_ln_no))
  (let Res Ln_no))
   (reset> This)
   (let Res Res))
(prog #not a member
   (=: new_buf (fltr_mtchng_hdng_rmndrs Ln))
   (if (<> (: new_buf) NIL)
  (if (=0 (: first_ln_no))
 (=: first_ln_no Ln_no))
  (reset> This))
   (let Res 0)

On 31 January 2017 at 16:27, dean  wrote:

> Each one of the "let"s in the following method WAS a setq. All I did was
> wrap the existing body with parens and assign Ln and Res with "let" but it
> doesn't work. The examples I've seen tend to be like this...
> (let X 3
>
> )
>
>
>
>
> )
>
>
> On 30 January 2017 at 16:19, dean  wrote:
>
>> Hi Alex
>> Yes that worked great preceded by a testi.e. whizzing through all
>> file lines in the input file until almost the 4000th which triggered
>> reporting on the method of interests's input and output. Thank you very
>> much for the advice.
>> Best Regards
>> Dean
>>
>> On 30 January 2017 at 11:07, Alexander Burger 
>> wrote:
>>
>>> Hi Dean,
>>>
>>> > trace operates in debug mode but again am not exactly sure how to
>>> ensure
>>> > that I am in debug mode on a method (rather than a function which is
>>> just
>>> > (debug 'Fn) at that point.
>>> > I have tried but get can't trace.
>>>
>>> While (trace 'foo) traces a function, (trace 'meth> '+Class) traces a
>>> method.
>>>
>>> ♪♫ Alex
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>
>>
>

Re: (NIL) vs Nothing

[dean]

Each one of the "let"s in the following method WAS a setq. All I did was
wrap the existing body with parens and assign Ln and Res with "let" but it
doesn't work. The examples I've seen tend to be like this...
(let X 3

)




)


On 30 January 2017 at 16:19, dean  wrote:

> Hi Alex
> Yes that worked great preceded by a testi.e. whizzing through all file
> lines in the input file until almost the 4000th which triggered reporting
> on the method of interests's input and output. Thank you very much for the
> advice.
> Best Regards
> Dean
>
> On 30 January 2017 at 11:07, Alexander Burger  wrote:
>
>> Hi Dean,
>>
>> > trace operates in debug mode but again am not exactly sure how to ensure
>> > that I am in debug mode on a method (rather than a function which is
>> just
>> > (debug 'Fn) at that point.
>> > I have tried but get can't trace.
>>
>> While (trace 'foo) traces a function, (trace 'meth> '+Class) traces a
>> method.
>>
>> ♪♫ Alex
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
>

Re: (NIL) vs Nothing

[dean]

Hi Alex
Yes that worked great preceded by a testi.e. whizzing through all file
lines in the input file until almost the 4000th which triggered reporting
on the method of interests's input and output. Thank you very much for the
advice.
Best Regards
Dean

On 30 January 2017 at 11:07, Alexander Burger  wrote:

> Hi Dean,
>
> > trace operates in debug mode but again am not exactly sure how to ensure
> > that I am in debug mode on a method (rather than a function which is just
> > (debug 'Fn) at that point.
> > I have tried but get can't trace.
>
> While (trace 'foo) traces a function, (trace 'meth> '+Class) traces a
> method.
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: (NIL) vs Nothing

[Alexander Burger]

Hi Dean,

> trace operates in debug mode but again am not exactly sure how to ensure
> that I am in debug mode on a method (rather than a function which is just
> (debug 'Fn) at that point.
> I have tried but get can't trace.

While (trace 'foo) traces a function, (trace 'meth> '+Class) traces a method.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: (NIL) vs Nothing

[dean]

I'm applying a method mthd> *Obj to each line of a file in turn. I've
tracked a problem down to when that method operates on line 3738 but am
unsure of exactly how to trace the method from that point on. I see that
trace operates in debug mode but again am not exactly sure how to ensure
that I am in debug mode on a method (rather than a function which is just
(debug 'Fn) at that point.
I have tried but get can't trace.
Any help much appreciated.

On 29 January 2017 at 15:29, dean  wrote:

> I've just tried sprinkling (!) in my source.
> That is going to help me A LOT. It looks like the PL equivalent of int 3 :)
> .
> .
>
> On 29 January 2017 at 15:19, dean  wrote:
>
>> Hi Alex
>> Thank you for the adviceI've just this minute used debug by
>> coincidence...but not with breakpoint and I've never used trace.
>> so thank you for those and also for putting me straight re the
>> positioning and syntax of (let (A 1 B 2..
>> Please have a good rest of the weekend.
>> Best Regards
>> Dean
>>
>> On 29 January 2017 at 14:42, Alexander Burger 
>> wrote:
>>
>>> Hi Dean,
>>>
>>> > I'm tending to develop functions in isolation so I can watch them like
>>> a
>>> > hawk.
>>>
>>> Watching like a hawk is always good! ;)
>>>
>>> In addition to that, I would recommend to use 'trace' and 'debug'.
>>> Especially
>>> 'trace' is more useful than it may seem, letting you monitor your whole
>>> program's behavior selectively. Individual functions can be
>>> single-stepped with
>>> 'debug', or by manually setting a breakpoint '!' with 'edit' or in the
>>> source
>>> code.
>>>
>>>
>>> > (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.
>>>
>>> Just move '(let Some_sym ...' up.
>>>
>>>
>>> > (let A 1 B2
>>> >
>>> > write your program as usual here safe in the knowledge that you have
>>> access
>>> > to A and B
>>>
>>> I think you mean
>>>
>>>(let (A 1  B 2)
>>>   ... )
>>>
>>> ♪♫ Alex
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>
>>
>

Re: (NIL) vs Nothing

[dean]

I've just tried sprinkling (!) in my source.
That is going to help me A LOT. It looks like the PL equivalent of int 3 :)

Re: (NIL) vs Nothing

[dean]

Hi Alex
Thank you for the adviceI've just this minute used debug by
coincidence...but not with breakpoint and I've never used trace.
so thank you for those and also for putting me straight re the positioning
and syntax of (let (A 1 B 2..
Please have a good rest of the weekend.
Best Regards
Dean

On 29 January 2017 at 14:42, Alexander Burger  wrote:

> Hi Dean,
>
> > I'm tending to develop functions in isolation so I can watch them like a
> > hawk.
>
> Watching like a hawk is always good! ;)
>
> In addition to that, I would recommend to use 'trace' and 'debug'.
> Especially
> 'trace' is more useful than it may seem, letting you monitor your whole
> program's behavior selectively. Individual functions can be single-stepped
> with
> 'debug', or by manually setting a breakpoint '!' with 'edit' or in the
> source
> code.
>
>
> > (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.
>
> Just move '(let Some_sym ...' up.
>
>
> > (let A 1 B2
> >
> > write your program as usual here safe in the knowledge that you have
> access
> > to A and B
>
> I think you mean
>
>(let (A 1  B 2)
>   ... )
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: (NIL) vs Nothing

[Alexander Burger]

Hi Dean,

> I'm tending to develop functions in isolation so I can watch them like a
> hawk.

Watching like a hawk is always good! ;)

In addition to that, I would recommend to use 'trace' and 'debug'. Especially
'trace' is more useful than it may seem, letting you monitor your whole
program's behavior selectively. Individual functions can be single-stepped with
'debug', or by manually setting a breakpoint '!' with 'edit' or in the source
code.


> (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.

Just move '(let Some_sym ...' up.


> (let A 1 B2
> 
> write your program as usual here safe in the knowledge that you have access
> to A and B

I think you mean

   (let (A 1  B 2)
  ... )

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: (NIL) vs Nothing

[dean]

If we take objects as an example...You might want to use these to create
static variables using object properties which you want to persist within a
limited scope. You might setq the object itself to make it persist but do
you manipulate the objects properties (that you want to persist) using setq
or let inside the object's methods. I'm sure the answer will become clear
after experimenting with let but I'm not sure at the moment.

On 29 January 2017 at 11:47, dean  wrote:

> Hi Chrostophe and Alex
>
> Thank you very much for your adviceIt 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
> i.e.
>
> (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)
> )
> 1
>
>
> I would like to crack this so any advice re how to correctly use "let"
> would be very welcome and appreciated. BTWPL's object system is a
> pleasure to use. Thank you for it!
>
> Best Regards
> Dean
>
>
>
>
>
>
>
>
> On 28 January 2017 at 19:13, Alexander Burger  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
>>
>
>

Re: (NIL) vs Nothing

[dean]

Hi Chrostophe and Alex

Thank you very much for your adviceIt 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
i.e.

(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)
)
1


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

Best Regards
Dean








On 28 January 2017 at 19:13, Alexander Burger  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
>

Re: (NIL) vs Nothing

[Alexander Burger]

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

Re: (NIL) vs Nothing

[Christophe Gragnic]

Hi all,

On Fri, Jan 27, 2017 at 7:01 PM, dean  wrote:
> I've got this filtering function
>
> (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.
I'd add (please confirm):
1) especially in function definitions, as
2) it creates/modifies like «global variables», which many consider
bad practice.


chri
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: (NIL) vs Nothing

[dean]

That' greatthank you for both examples.

On 27 January 2017 at 19:03, Alexander Burger  wrote:

> Hi Dean,
>
> > (de fltr (Buf Ln)
> >(setq New_buf (mapcar '((Ele) (pack (tail (- (length Ln)) (chop
> Ele
> >   (filter '((Ele) (pre? Ln Ele)) Buf
> > ...
> > #: (fltr '(aa ab) 'ab)
> > #-> (NIL)
>
> You can use 'extract' to get exactly the results you need:
>
>(de fltr (Buf Ln)
>   (let N (inc (length Ln))
>  (extract
> '((Ele)
>(when (pre? Ln Ele)
>   (pack (nth (chop Ele) N)) ) )
> Buf ) ) )
>
>
> Perhaps 'match' is more elegant than 'pre?' and 'nth' or 'tail':
>
>(de fltr (Buf Ln)
>   (let Pat (conc (chop Ln) '(@Rest))
>  (use @Rest
> (extract
>'((Ele)
>   (and (match Pat (chop Ele)) (pack @Rest)) )
>Buf ) ) ) )
>
> In both cases:
>
>: (msg (fltr '(aa ab abc) 'ab))
>-> ("c")
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: (NIL) vs Nothing

[Alexander Burger]

Hi Dean,

> (de fltr (Buf Ln)
>(setq New_buf (mapcar '((Ele) (pack (tail (- (length Ln)) (chop Ele
>   (filter '((Ele) (pre? Ln Ele)) Buf
> ...
> #: (fltr '(aa ab) 'ab)
> #-> (NIL)

You can use 'extract' to get exactly the results you need:

   (de fltr (Buf Ln)
  (let N (inc (length Ln))
 (extract
'((Ele)
   (when (pre? Ln Ele)
  (pack (nth (chop Ele) N)) ) )
Buf ) ) )


Perhaps 'match' is more elegant than 'pre?' and 'nth' or 'tail':

   (de fltr (Buf Ln)
  (let Pat (conc (chop Ln) '(@Rest))
 (use @Rest
(extract
   '((Ele)
  (and (match Pat (chop Ele)) (pack @Rest)) )
   Buf ) ) ) )

In both cases:

   : (msg (fltr '(aa ab abc) 'ab))
   -> ("c")

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

re (NIL) vs nothing

[dean]

re my last post/thread
I don't want to waste anyone's time so please hold fire...
I've split the filtering and chopping in two and even the filtered member
LIst is disappearing
(as a result of just filtering (when it shouldn't)
so the problem doesn't look like it's to do with chopping the values down
to NIL.
I'll keep working on it.
Best Regards
Dean