Ken Tilton  <kentilton@gmail.com> wrote:
+---------------
| Rob Warnock wrote:
...
| > ...why not have one that's at least efficient and perspicuous *and*
| > also incidentally preserves the order of the input values?  ;-}
| >     (defun separate (list)
| >       (loop for item in list
| > 	when (zerop item)
| > 	  collect item into zeroes
| > 	else when (plusp item)
| > 	  collect item into positives
| > 	else 
| > 	  collect (abs item) into negatives
| > 	finally (return (list positives zeroes negatives))))
| 
| That was mine until I remembered a requirement that the solution be 
| "side-effect safe", which I assume is a misreporting of the teacher's 
| requirement that it be "side-effect free".
+---------------

I didn't read it that way, which is why I thought using LOOP...COLLECT
would be fine.

To me, "side-effect safe" meant that the *inputs* were to be safe
from side effects, not that no internal implementation of a CL builtin
had to be free of mutation under the hood. After all, with the
fabled "sufficiently smart compiler", it *is* possible to implement
LOOP...COLLECT by pushing onto the head of an internal anonymous
[or GENSYM'd] list and then making the collection variable be a
SYMBOL-MACROLET for (REVERSE #:Gnnn), yes? So the LOOP...COLLECT
version *might* be "side-effect free" [for whatever good that does],
but in any event the LOOP...COLLECT version is always at least
"side-effect safe".

Anyway, in the immortal workds of Colin Quinn,
"that's my story & I'm sticking to it..."[1]


-Rob

[1] Which <http://en.wikipedia.org/wiki/Colin_Quinn> says actually
    came from the 1993 country song by Collin Raye, but who's quibbling?

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607