development release newLISP version 9.9.2

[Lutz]

Thanks for all the corrections and errata.



Regarding setq/setf: In newLISP 9.9.2 'setq' and 'setf' point to the same internal function. I still think the normal 'set' is needed for things like this:

Code Select Expand

> (set 'l '(a b c))
(a b c)
> (set (first l) 123)
123
> a
123


with only setf/setq you would have to do:

Code Select Expand

> (setf (eval (first l)) 456)
456
> a
456
>


using the extra 'eval'.



'set setq setf' is one of those things you can discuss eternally without finding agreement ;-) Perhaps its not a bad idea to have several of them. As syntax is almost non-existent in Lisp, the different versions help to communicate your intentions. In the manual I also recommend to use 'setq' for variables and 'setf' for references.



You know, you always can do: (constant 'set setf)

Or in order not to confuse everybody else: (constant 'assign setf)

Or how about this: (constant '<- setf)



The way newLISP works, all of these are equally fast.



ps: for several versions newLISP also had 'set!' but nobody ever used it.

[newBert]

As for me I like the way NewLISP is developing. Some of my scripts, after all quickly modified, are really faster ! I realized this with my own eyes, without the help of any benchmarking :-)



It's sure that all three set(s) (set, setq, setf) must be preserved, at least for readability and expressiveness, but not only ... as Lutz explained.



Thank you for these changes, that also gave rise to review and optimize some of my scripts ;-)

[Kazimir Majorinc]

Kazimir:



Any of these solutions must be able to recover the original variable environment without cell leaks and multiple memory-object references in case of early functions return when errors occur, or when 'catch' and 'throw' is involved. Only symbols and contexts are exempted.

If you introduce new kind of function, and these functions do not cooperate well with some elements of language, like catch and throw - so what? Those who need catch and throw lose nothing, those who do not need catch and throw get something. If in the future you find the way to extend catch and throw on new functions, it is additional bonus.



It is usually that way with generalizations. They have the price.