first gives errors on empty lists

[shercipher]

Calling (first) on an empty list gives an error instead of returning the empty list. This is inconsistent with the documentation, which claims that first behaves the same as car in other Lisp implementations.

On the contrary,

Code: Select all

; sbcl
This is SBCL 1.0.18.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http>.

* (car nil)

NIL

* (car ())

NIL

CL (and Scheme as well, I believe) return empty lists when car or cdr (which are first and rest in NL) are called on empty lists.

This behavior of the function gives a lot of errors in instances where lists are being checked using functions such as filter, which may return empty lists. I doubt that modifying this behavior would cause existing programs to break.

[Lutz]

In Common Lisp 'nil' is a list terminator in newLISP 'nil' is a boolean value only. Consider this in SBCL:

Code: Select all

* (car '())

NIL
* (car '(nil))

NIL
* 

but in Scheme and newLISP things are similar, in SISC (R5RS Scheme) :

Code: Select all

#;> (car '())
Error in car: expected type pair, got '()'.
console:3:1: <from>
#;> (car '(nil))
nil
#;> 

and in newLISP similar:

Code: Select all

> (first '())

ERR: list is empty in function first : '()
> (first '(nil))
nil
> 

Both Scheme and newLISP give an error when using 'car' or 'first' on an empty list. The documentation does not use the word same but uses the weaker equivalent. I don't want to go too much into these type of differences in the newLISP manual, but I could add your observation here:

http://www.newlisp.org/index.cgi?page=D ... ther_LISPs

perhaps an additional paragraph after the explanations about 'cons' or in the paragraph about 'nil' and 'true'.

[shercipher]

Right, maybe this is just another "nil is not ()" difference with Common Lisp. Sorry, CL was what taught me how to think Lisp.

[Lutz]

Many of the differences between CL and newLISP have their root in the fact that CL is designed to be compiled, while newLISP is a dynamic, interpreted and code equals data language.

Apart from those differences you will find enough other things in newLISP being similar to what attracted you to Lisp in the first place.