correct behaviour of nconc

Discussion of Common Lisp
Post Reply
Martin Kalbfuß
Posts: 12
Joined: Fri Jul 24, 2015 5:27 am

correct behaviour of nconc

Post by Martin Kalbfuß » Fri Jul 24, 2015 5:44 am

Hi guys,
I'm currently implementing my own lisp interpreter. At the moment I working on the function nconc. I'm not sure how it should behave for the following cases:

Code: Select all

(nconc 1)
or

Code: Select all

(nconc nil 1)
The gnu common lisp compiler returns 1 for both cases. Shouldn't the return value be a list. Isn't throwing an exception the better behaviour? Or is this behaviour forced by the standard?

regards,
Martin Kalbfuß

Goheeca
Posts: 271
Joined: Thu May 10, 2012 12:54 pm
Contact:

Re: correct behaviour of nconc

Post by Goheeca » Sat Jul 25, 2015 2:31 am

By the description section in CLHS you apply 2nd and 3rd rules.
[2] (nconc nil . lists) == (nconc . lists)
[3] (nconc list) => list
For your first code you apply the 3rd rule and
The last list may be any object.
That's:

Code: Select all

(nconc 1) => 1
For your second code you apply the 2nd rule then the 3rd one:

Code: Select all

(nconc nil 1) == (nconc 1) ;;; is equal to (nconc nil . (1)) == (nconc . (1))
(nconc 1) => 1
cl-2dsyntax is my attempt to create a Python-like reader. My mirror of CLHS (and the dark themed version). Temporary mirrors of aferomentioned: CLHS and a dark version.

edgar-rft
Posts: 226
Joined: Fri Aug 06, 2010 6:34 am
Location: Germany

Re: correct behaviour of nconc

Post by edgar-rft » Sat Jul 25, 2015 10:21 am

While Goheecha's explanation is correct, an easier-to-understand explanation is that NCONC is the destructive version of APPEND, which is defined as:
CLHS APPEND wrote:... The last argument is not copied; it becomes the CDR of the final dotted pair of the concatenation of the preceding lists, or is returned directly if there are no preceding non-empty lists.
- edgar

Post Reply