Search code examples
schemeracketsicpmit-scheme

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


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


Solution

  • 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)