Hi Lutz,
Some questions regarding Rel 10
I dont understand why "setf" was introduced and not "setq" extended
with the features 'setf now has..would that not be more logical?
(breaking the meaning of 'setq is not the case here i think..)
Secondly.. ->
** push now returns the modified list instead of the element pushed. ***
What about lists that extend 100000+ entry's? isnt this then a slowdown factor?
And last ->
Should some function inside newlisp that return 'nil or true not be
changed because of the fact that newlisp now returns "out of bound..."
messages?
i.e.
(not ( '() 1))
should return 'nil and not -> ERR: list index out of bounds in function not
Its somewhat confusing..
Norman.
Quote
with the features 'setf now has..would that not be more logical?
'setq' does work like 'setf' now, the second 'setf' naming is a concession to other Lisp dialects. I stopped short of having only one 'set' and abolish all others, perhaps in version 20.0 ;-)
Quote
'push' returns a reference to the list (like all destructive functions now), so there is no speed penalty returning a big list. Read about reference returns in the 10.0 release notes.
why is that confusing ( '() 1) ? The empty list has 0 elements, so and index of 1 is out of bounds. The 'not' has nothing to do with this.
Yes im studing the Rel 10 notes now.. I must say very nice enhancements!
Well yes ..the 'not..
because from the manual point of view 'not returns 'true or 'nil
like (not '(1)) returns 'nil
so a not on an indexed list returns a string "...out of..." and not 'nil or 'true..
So my point here is that the string syntax-return breaks some default
return values actualy..
'not' negates the argument, returning 'nil' for everything not 'nil'. But in (not '() 1), 'not' never comes to execute, because the error gets thrown earlier by the inner expression.
Only indices in 'slice' or implicit slicing/resting can be overrun. This is useful for frequent constructs like: "take all elements starting at position idx but now more than size"
Thanks..
Btw.. what is this for ? ->
char preLoad[] =
"(define Tree:Tree) (define (Class:Class) (cons (context) (args)))";
Quote from: "Lutz"
Only indices in 'slice' or implicit slicing/resting can be overrun. This is useful for frequent constructs like: "take all elements starting at position idx but now more than size"
Ok, so can I catch this? That is, is this a catchable error, or do I always have to erect a superstructure of list checking to make sure the reference will succeed? Do you have time to tell us a bit about the design decisions that went into this? Does it make newlisp faster and more efficient?
I was just bit by this feature of newlisp. To this newbie, it seems this behavior violates the principle of least suprise.
I withdraw my question; I read up on the catch function and everything is hunky dory.