I'm not a great programmer, but [...]
My guess at this point is that my latest modifications of the C-interface must be causing a problem when a garbage collection occurs during a Scheme to C call. I'm looking into it.
Thanks, Marc! I've been having a crazy Emacs problem all morning, I wonder if anyone else ever got that. Finally I saw the problem in DrScheme, and how to fix it with some Emacs. Possibly it was caused by quack.el, but switching over to gambit.el didn't fix it.
So here's a simple file "hatA":
(define (memf p alox) (if (null? alox) #f (if (p (car alox)) alox (memf p (cdr alox)))))
(write (memf odd? '(2 8 2 3 5 4 1 2 3 4))) (write (memf odd? '(2 8 2 30 50 4 10 2 30 4)))
(banach)lambdaGambit> gsi hatA *** ERROR IN "hatA"@8.9 -- Unbound variable: memf
By looking at the file in DrScheme, I saw I have a \hat{A} character after memf. I can see the \hat{A} character in this mail buffer.
I asked someone here, and he noted that my modeline was reading "u" on the far left. The Emacs manual (`s' for "mode line") in the node "Coding Systems" says type C-h C RET, and I see I'm using "u -- mule-utf-8 (alias: utf-8)". Durn! Reading more of the manual, I see to try M-x find-file-literally, and I backspace over the 2 \hat{A} characters, and the "space" in front of it. I can see by C-s that there are only 2 such "space"s in the whole file. And now it's fine:
(banach)lambdaGambit> gsi hatA (3 5 4 1 2 3 4)#f
Whew! Anyone has a tip to stay out of this problem in the future?