Crash on local variable, but not on global

[SigmaX]

I'm running two bits of code that I thought would do the exact same thing. One crashes, the other doesn't.

The working one:

Code: Select all

(loop for i from 0 to 20 do (setf *pool* (add_rand_circuit *needs_pool* *pool*)))

Where *pool*, of course, is global.

The non-working one:

Code: Select all

(defun meh (pool) (loop for i from 0 to 20 do (setf pool (add_rand_circuit *needs_pool* pool))))
(setf *pool* (meh *pool*))

Which crashes (if you must know, it's "*** - +: NIL is not a number").

So, without going into detail about what add_rand_circuit does, can somebody tell me if there is some sort of, I dunno, size limit or other significant difference between a global variable and a local variable? The same thing happens if I replace "pool" in the "meh" function with a let variable.

Thanks a mil,
Siggy

[ramarren]

First, two things which should be unrelated: if you are not using the iteration counter, it is better to replace the clause with (loop repeat 20 ...), second, without any collection or reduction clauses and without an explicit return LOOP returns NIL, so your (setf *pool* (meh *pool*)) actually sets *pool* to NIL.

There should be no differences with code as shown. It is possible that either *pool* is really a symbol macro, or that the add_rand_ciruit refers to *pool* directly, which would break. It is impossible to say more without seeing more of the code or a reduced test case.

[SigmaX]

(loop repeat 20 ...)

Thanks. The more you know...

without any collection or reduction clauses

Heh, you're totally right. It's a simplified version of my real (more complex) function, which has a finally clause.

It's possible that add_rand_circuit or one of its subfunctions refers to *pool* directly somewhere. I'll go sift through my code.

Thanks,
Siggy

[SigmaX]

Yeah, that was it. Looks like one of my functions assumed that *pool* is updated every time I add something. I was trying to add several things at once.

Good. I was afraid my world was going to be turned upside-down by some strange quirk regarding variables in the local stack .

Siggy