Why does this return a list '(5) rather than the number 5?

Question

I am working through SICP, and the exercise I am working on asks for a procedure that returns the last element in a list. I implemented the procedure last-pair to do this, but I'm confused why it's returning a list rather than a number:

(define (last-pair alist)
  (cond ((null? (cdr alist))
         (car alist))        ; still happens if this is just "car alist)"
        (else
         (last-pair (cdr alist)))))

When I invoke it on a list of the integers from 1 to 5, I get the output '(5):

> (last-pair (list 1 2 3 4 5))
'(5)

I was expecting 5, like how (car (list 1 2 3 4 5)) would return 1 not '(1).

Why do I get '(5) and not 5?

I'm using DrRacket 5.3.3 and Racket Scheme.

EDIT 1: MIT-Scheme does not appear to do this. last-pair returns 5 not '(5). Which is correct?!?

EDIT 2: Interestingly, in DrRacket (not in MIT-Scheme), if the second line (cond ((null? (cdr alist)) is indented two spaces, when the procedure is called, it returns '(5). But, when the second line is not indented, it returns 5. Is this a glitch? I believe all that Scheme interpreters are supposed to follow is parentheses, correct?

EDIT 3: I am beginning to think this is a glitch in DrRacket. When I place the procedure definition in the definitions window (typically the top editor pane), regardless of indentation, the procedure will return 5. But, if I define it in the interface window, ~~the indentation affects the result as described in Edit 2.~~ (EDIT 4) regardless of the indentation also, it will return '(5).

< snipped prevous part with some code about differences in indentation; the problem now is just where the procedure is defined, see Edit 4 >

EDIT 4: Ok I have simplified the problem.

In MIT-Scheme, (last-pair (list 1 2 3 4 5)) returns 5, where last-pair is defined above. Regardless of indentation.
In DrRacket, when the last-pair procedure is defined in the definitions window, and then I click "Run", (last-pair (list 1 2 3 4 5)) returns 5. Regardless of indentation.
In DrRacket, when the last-pair procedure is defined in the interface window (the REPL), (last-pair (list 1 2 3 4 5)) returns'(5). Regardless of indentation.

Here's a screenshot: Racket gives different results for same function defined in different windows

Can not replicate yet. Note that if you are entering definitions in the interactions, you may be running into a messy collision with the existing definition of last-pair defined in the Racket language: docs.racket-lang.org/reference/… It is much safer to keep all your definitions in the Definitions pane, and just treat the Interactions pane as a place to explore those definitions. — dyoo
Also note that the comment notation in Racket uses semicolons, not hashes. Does your real program have hashes? — dyoo
@dyoo no my real program does not; I have edited the question. — kalaracey
you know, last-pair is a standard function name, and it returns a last pair, not a last element like you want it to. Maybe DrRacket refuses to redefine it, silently, when you enter the new definition at the REPL. Try the same definition with a different name, at the REPL, and tell us what happens. :) — Will Ness

Will Ness Will Ness · Accepted Answer · 2013-04-01T09:58:56

Better don't use the built-in name last-pair. I suggest using something more descriptive of what you expect, like last-elem for example.

When renaming your function, be sure to rename it throughout; i.e. change the name of the function not only at the definition site, but also at each call site, including of course inside its body, where it gets called recursively. Renaming must be performed diligently, it is very easy to introduce new errors otherwise.

About the strange behaviour at the REPL. My guess is, when you entered

(define (last-pair alist)             ;; definition
  (cond ((null? (cdr alist))
         (car alist))        
        (else
         (last-pair (cdr alist)))))   ;; call

at the REPL, the last-pair at the call site still referred to the built-in definition from the "outer" environment, so this call wasn't recursive. If that is the case, REPL did redefine the built-in, it's just that the call wasn't recursive.

I'd expect making an internal definition with explicit letrec should fix it, even when entered at the REPL:

(define (last-pair alist)
  (letrec ((last-pair (lambda (alist)          ;; internal definition
             (cond ((null? (cdr alist))
                (car alist))        
              (else
                (last-pair (cdr alist)))))))   ;; recursive call
     (last-pair alist)))                       ;; first call

because the first call now calls into the recursive internal version explicitly, being inside the letrec form. Or maybe it'll get screwed somehow too, but I'd be really surprised if it did. :) Translating defines without internal definitions as simple lambda forms is one thing; messing inside the explicit letrec is quite another.

If this indeed works it'll mean that the Racket REPL translates simple definitions like (define (f x) ...body...) as simple lambda forms, (define f (lambda(x) ...body...)), not as letrec forms, (define f (letrec ((f (lambda(x) ...body...))) f)). And also, that define at the Racket REPL does not alter the old binding in the global environment, but adds a new binding into it on top of the old, shadowing the old binding.

This suggests yet another way to "fix it" at the REPL — with set!:

> (define f #f)
> (set! f (lambda(x) ...body...))  ; alter the old binding explicitly 
> (f x)

Why does this return a list '(5) rather than the number 5?

2 Answers