Quick puzzle: why does this program return the wrong answer:
#lang typed/racket
(: process-number (Integer -> (U 'both-odd 'not-both-odd)))
(define (process-number n)
(if (andmap is-odd? (list (sub1 n) (add1 n)))
'both-odd
'not-both-odd))
(: is-odd? (Integer -> (U 'odd 'even)))
(define (is-odd? n)
(if (= (modulo n 2) 0)
'even
'odd))
(process-number 13) ;; > returns ‘both-odd
this program suggests that both 12 and 14 are odd numbers. Can you see the bug?
…
^L
Okay, so: couldn’t TR have found this bug for me? Yes, it definitely could
have. In fact, if you hover over the type of the test argument, you’ll see that
the else is unreachable. And, in the larger program that I first encountered
this bug in running the optimization coach and turning on the “warning” section
of the log actually identifies unreachable code, clearly indicating the
location of the bug.
So, I have two questions:
1) Why doesn’t the optimization coach locate the unreachable code in this
example? Perhaps it’s too small?
… but probably harder and more interesting:
2) Is there some nice user interface that we could use to make the warnings
visible to the case of the user? Maybe a “I think I have a bug, can I see the
compilation warnings” button?
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
