I'm using SBCL with Slime and Emacs on my MacBookPro.
I'm playing around with permutations expresssed as cycles and wrote the
following two functions:
; Clearly not the most efficient way to do it, but fine for now
; For instance
; (cycle-successor 3 '(1 3 2 4)) should return 2
; (cycle-successor 4 '(1 3 2 4)) should return 1
(defun cycle-successor (n cyc)
(declare (integer n))
(declare (sequence cyc))
"Finds the successor to n a cycle containing it
-- returns n if not in the cycle"
(let ((l (- (length cyc) 1))
(s (position n cyc)))
;(format t "l: ~d, s: ~A" l s)
(cond ((null s) n)
((eql s l) (nth 0 cyc))
(t (nth (+ 1 s) cyc)))))
; Use it to find the successor in a product of cycles
; For instance
; (cycle-product-successor 3 '((1 3 2 4) (1 4 2 3) (2 3 1 4)))
; should return 1
(defun cycle-product-successor (n cycles)
"Finds the successor to n in the product of the given cycles
-- or NIL if in none"
(if (null cycles)
n
( cycle-product-successor
(cycle-successor
n
(first cycles))
(rest cycles))))
If I copy and paste these into the *slime-repl sbcl* buffer, they work
fine.
If, however, I attempt to compile them, the second defun claims to
redefine cycle-successor and (fboundp cycle-product-successor ) returns
nil.
If I replace that definition with the following, it compiles fine, and
works.
(defun cycle-product-successor (n cycles)
"Finds the successor to n in the product of the given cycles
-- or NIL if in none"
(cond
((null cycles) n )
(t ( cycle-product-successor (cycle-successor n (first cycles))
(rest cycles))
)))
My guess is that if is a macro and I'm hitting some interesting
interaction I don't yet understand, presumably the macro yeilds
something close to the second definition.
I guess my questions are:
a) would I have expected this behavior, were I more knowledgeable?
b) if not, is it a bug?
assuming it's not a bug, what do I need to read / understand to avoid
the mistake in the future?
joe
On Jul 10, 11:31 pm, Joe Davison <····@ieee.org> wrote:
> I'm using SBCL with Slime and Emacs on my MacBookPro.
...
> If I copy and paste these into the *slime-repl sbcl* buffer, they work
> fine.
> If, however, I attempt to compile them, the second defun claims to
> redefine cycle-successor and (fboundp cycle-product-successor ) returns
> nil.
This isn't what I observe here, with SBCL 1.0.7 & SLIME on my macbook.
In any case, cond being a macro is extremely unlikely to have anything
to do with your problem.
Paul Khuong
On Jul 10, 11:31 pm, Joe Davison <····@ieee.org> wrote:
> If I copy and paste these into the *slime-repl sbcl* buffer, they work
> fine.
> If, however, I attempt to compile them, the second defun claims to
> redefine cycle-successor and (fboundp cycle-product-successor ) returns
> nil.
>
I copied and pasted them into a Slime scratch buffer and compiled them
with SBCL 1.0.7.13 and did not get the result you described. That is,
everything compiled without any redefinition errors. Both the COND
and IF versions worked without a problem.
Check the macroexpansion of the COND to see if you mistyped something
in your code but pasted it correctly into c.l.l. :)
On Tue, 10 Jul 2007, Geoff Wozniak wrote:
> I copied and pasted them into a Slime scratch buffer and compiled them
> with SBCL 1.0.7.13 and did not get the result you described. That is,
> everything compiled without any redefinition errors. Both the COND
> and IF versions worked without a problem.
>
Hmmmm...
I was having the problem when using slime-compile-defun from my editor
buffer, didn't try compiling after cutting & pasting into the slime-repl
buffer.
Must have had a typo somewhere when I tried this before -- today it's
working ...
Thanks,
joe
I liked it better back when computers were deterministic...