2

Upon compile, SBCL complains that (mod number 10) is unreachable in

(defun foo (number)
  (cond
    ((> number 10) (mod number 10))
    (t number)))

Why is this so?

The full compiler message:

; in: DEFUN FOO
;     (MOD NUMBER 10)
; --> LET IF AND IF IF PLUSP > 
; ==>
;   NUMBER
; 
; note: deleting unreachable code
alcorn
  • 1,268
  • 1
  • 8
  • 17
  • I can't reproduce on SBCL or GNU CLISP. What version, and what command are you using to compile? – Silvio Mayolo Nov 18 '20 at 20:54
  • SBCL 1.4.5.debian. I'm using C-c C-c from within the SLIME environment v2.20 – alcorn Nov 18 '20 at 21:22
  • 1
    Very interesting. It *does* do that inside of SLIME, but when I load from the command line it doesn't. I wonder what warnings SLIME is enabling that aren't on by default. – Silvio Mayolo Nov 18 '20 at 21:31
  • Thanks for corroborating. Assuming SLIME is right that `(mod number 10)` can be deleted, I can't see how it would do that while maintaining the function of `foo`. Any ideas? – alcorn Nov 18 '20 at 21:34
  • And how did it come up with `let if and if if plusp`? – alcorn Nov 18 '20 at 21:35
  • After copy-pasting your code into an emacs buffer and sending the function definition to the REPL with C-c C-c, it works fine for me. I can't reproduce, but I am using Slime 2.26 with SBCL 2.0.10. – ad absurdum Nov 18 '20 at 21:57
  • I should mention I'm using SBCL 1.4.5.debian on SLIME v2.26, so it makes sense I would get similar results to OP. – Silvio Mayolo Nov 18 '20 at 22:03
  • I suspect strongly that what you are seeing is deletion of code from whatever `(mod number 10)` has turned into, possibly based on the fact that the compiler knows a lot about the type of `number` at that point (it's a positive real). –  Nov 19 '20 at 13:05

1 Answers1

2

Looking at the comments, it's most likely dead code elimination of code that (mod number 10) expanded to. On SBCL 2.0.0 and later, I'm not able to reproduce the warning.

AKA Compiler 'bug'

Wilfredo Velázquez-Rodríguez
  • 132
  • 7