PS does the following to warn you about redefining built-in operators:<div><br></div><div>  (warn "Redefining Parenscript operator/macro ~A" name)</div><div><br></div><div>As it happens, we redefine DEFMACRO and IN-PACKAGE to expand to nothing</div>

<div>and @ to expand to something a bit different than what PS does. The purpose</div><div>of these redefinitions is to support cross-compiling a number of files to both CL</div><div>and JS.</div><div><br></div><div>Unfortunately, that warning turns into an error preventing ASDF from loading</div>

<div>the system in SBCL:</div><div><br></div><div><div><div>; compilation unit aborted</div><div>;   caught 1 fatal ERROR condition</div><div>;   caught 3 WARNING conditions</div></div></div><div><br></div><div>I don't see what the ERROR is, since only the above three warnings</div>

<div>are written to the REPL. It goes away, however, when I comment out the WARN</div><div>form above.</div><div><br></div><div>I have an ugly workaround for this (reach in to PS::*PS-DEFINED-OPERATORS*</div><div>and rip out these three symbols before attempting to redefine them), but</div>

<div>that seems like a horrible thing to do. Resorting to SBCL's condition-muffling </div><div>mechanism seems even worse.</div><div><br></div><div>Just to be clear, I don't object to PS issuing the warning, just to the fact that</div>

<div>it turns into a fatal error along the way. So I guess my question is: what's the</div><div>intended way to redefine a PS operator/macro, on the rare occasion when one</div><div>really does need to do that?</div>
<div>
<br></div><div>Daniel</div><div><br></div>