currently:
> (integer 1)
1
> (integer "")
nil
> (integer nil)
missing argument in function integer
> (integer unbound 0)
value expected in function integer : nil
> (integer nil 0)
missing argument in function integer
Why are (integer nil 0) and (integer unbound 0) handled differently?
Lutz - would you consider allowing integer to return the default if the argument is nil? (would just tidy up some of my code - currently I check for nil prior to conversion).
In 7.5.15 if the datatype is not a string or a number in integer or float, then nil will be returned or the default value if specified:
(integer nil) => nil
(integer nil 0) => 0
(float nil) => nil
(float nil 0) => 0
previously this caused error messages
Lutz
This is intresting actualy, in newlisp 'nil is not represented with a
value conresponding 0. So 'nil could also be intepreted as being true or 1.
(> 1 nil) works so that assumes 'nil equals 0.
(= nil 0) says 'nil, which means 'nil is string and 0 is number.
Its sometimes confusing using 'nil, therefor i currently bypass it
and only use it as a return handler in functions.
The reason that (> 1 nil) returns 0 is that the comparison operator compares datatypes when the arguments are not equal different types (see the manual).
nil and 0 have nothing to do with each other!
nil is a boolean value and a symbnol nothing else. The expressions:
(integer nil 0) => 0 ; in version 7.5.15
(integer nil 123) => 123 ; in version 7.5.15
(integer 'abc 999) => 999
;;
(float nil 0) => 0 ; in version 7.5.15
(float nil 123) => 123 ; in version 7.5.15
will return the default value,
Lutz
yes your right about 'nil, still is funny to get confused about the meaning
of 'nil and 'null or even 0 , which are not the same :-)
Some programming languages take 0 as a boolean false in a boolean context (like 'C') , but this is not the case in newLISP, where only nil and the empty list () are taken as boolean false in a boolean context:
(if 0 'yes 'no) => yes
(if () 'yes 'no) => no
Lutz