development release newLISP v9.4.4

[Lutz]

* fixes and minor additions, see CHANGES notes for details



files and CHANGES notes: http://www.newlisp.org/downloads/development">http://www.newlisp.org/downloads/development

[newdep]

Its here 90F....too hot to touch a keyboard..

and was just passing my computer when i found this Summer-Release ;-)



...

 'inc' and 'dec' on a variable containing 'nil' assumes 0 contents, this

  makes initialization of variables used in 'inc' and 'dec' un-necessary,

  but is also compatible with existing code

...



Finally a language that does this (without compiler interaction) ...great!



PS: the $idx enhancement too !! nice nice...

[cormullion]

Yes, some nice improvements here, Lutz!



But I see you're planning to change the operation of unless in a future release - in a way that will break existing code. What was your reasoning behind agreeing to make this change? (I'm familiar with the argument that such a change could be seen as making newLISP more compatible with some other dialects of Lisp, as discussed on another thread. But I didn't find out what your view on that aspect of the topic was.)

[Jeff]

One thing I would like to see is to be able to inc/dec a dictionary expression, eg

Code Select Expand

(define foo:foo)
(inc (foo "bar")) ; => 1
(inc (foo "bar")) ; => 2
(foo "bar") ; => 2

[m i c h a e l]

Hi cormullion!



I think Lutz means that if-not will change in future to work like (when (not ...) ...). It currently works like unless, which will remain unchanged. But I could be wrong ;-)



m i c h a e l

[Kazimir Majorinc]

Hi cormullion!



I think Lutz means that if-not will change in future to work like (when (not ...) ...). It currently works like unless, which will remain unchanged. But I could be wrong ;-)



m i c h a e l

I understand that Lutz provided for some buffer time in which people like Cormullion can use both if-not and unless for the same thing, so their code is not broken, but in that time they have to replace reminding "unless" with "if-not." That time period can be quite long - if one does such kind of things he think in the long terms. Then, unless will change (and if-not will stay the same) and start to work like in CL and Scheme.



I also like that inc and dec, and it seems to me that it is special case of the principle that nil behaves as universal neutral element. 0 is neutral element for addition, and dec and inc are two special cases of addition. In CL, nil is empty list, which is again neutral element for many important operations. In my opinion it is very powerful idea, and if developed further it can eliminate majority of the initializations, and effectively reduce the size and "depth" of the algorithm intensive programs for more than 5%. Here is one artificial example where such a hypothetical policy reduces size of the program for about 30%. The first two versions of the code are with explicit initialization, other two with automatic one.

Code Select Expand

(if condition
   (begin (setq r 0)
          (dolist(i L)
               (setq r (+ r (f i)))))
   (begin (setq r 1)
          (dolist(i L)
               (setq r (* r (f i))))))
   
   ; Words: 26 Bytes: 184
;---------------------------------------  
(begin (setq r (if condition 0 1))
       (dolist (i L)
               (setq r ((if condition + *) r (f i)))))

   ; Words: 17 Bytes: 112 (Words: 16, Bytes: 90 without begin)
;---------------------------------------  
(if condition
   (dolist(i L)
           (setq r (+ r (f i))))
   (dolist(i L)
           (setq r (* r (f i)))))
           
   ; Words: 18 Bytes: 116
;---------------------------------------  
(dolist(i L)
       (setq r ((if condition + *) r (f i))))

   ; Words 10 Bytes: 59
   
 

So, I think it is good way to go and I hope we will see more of the similar uses of the nil in the future.



Is anyone aware of possible disadvantages of automatic initialization to neutral element?

[Lutz]

Its like Kazimir understood it: for some time 'if-not' and 'unless' will work the same having then and else clauses, then after some time 'unless' will lose the else clause and work like a (when (not ...) ...).



Besides compatibility I have the feeling that 'when' is getting quite popular among newLISP users, so having a reverse 'when' would be a good decision. For this 'unless' was the best word, the 'u' being close to the 'w'.

Code Select Expand

(if <cond> <then> <else>)
(if-not <cond> <then> <else>) ; currently like unless

(when <cond> <then> [<then> ...])
(unless <cond> <then> [<then> ...]) ; in a future version


[cormullion]

I still don't think there are enough valid reasons to make this change.



It's like botox for newLISP - a damaging change to the underlying base in order to achieve some dubious cosmetic benefits that are designed to appeal to people who probably won't appreciate the change anyway.



For every Common Lisp user who says "aha, at last, unless is fixed, I can now use newLISP" there'll be 100 who'll say "they can't even decide what the basic flow control words should be from one release to the next...".



:(

[Jeff]

Corm - I was against the change initially.  But I have found that when is an expressive operator.  When you look at code, you know that you do not need to visually look for alternate expressions if there is a when expression.  I find that I generally use unless in the same manner, and (if (not ...)) when I expect to have several options (in fact, I use if and if/not exclusively for two options, and cond when there are more).

[cormullion]

Yes, I use *when* a lot now. In fact I had wondered about the complementary function for *when* - a '*when-not*'. (Of course, *unless* is unavailable, since it's already paired with its complementary function *if*.) I had toyed with *despite* for a while...

[Kazimir Majorinc]

Besides compatibility I have the feeling that 'when' is getting quite popular among newLISP users, so having a reverse 'when' would be a good decision. For this 'unless' was the best word, the 'u' being close to the 'w'.

And there is one cute syntactic and semantic similarity



WHile = WHen repeated

UNtil = UNless repeated (in future meaning of the "unless")



There is no "If" repeated but as it is infinite loop it cannot be of great interest.



But infinite loop itself (say "repeat") is of some interest, it fits well with catch and throw. Although it is very easy to fake it with "while true", but then aesthetically, "while true" is an imperfection, like "when true" for "begin. "