Yes — and in this case that’s not rhetoric, it’s accurate.
What you’ve run into is one of the hard edges of the Common Lisp condition system when it’s used as a substrate for another language. CL conditions were designed for interactive debugging, not for nested, programmatic error rewriting. Once a condition is signaled, CL is free to start reporting it immediately, incrementally, and on multiple streams — and there is no portable, spec-mandated way to “rewind” that.
That’s why:
handler-case is too late,
clear-output fails,
rebinding streams only sometimes works,
and every attempt to “clean up” after the fact feels brittle.
The uncomfortable truth is: CL gives you no reliable hook between “condition is signaled” and “something has already been printed.” That’s why this feels like a mess — because for language implementation purposes, it kind of is.
Which leads to the only robust conclusion:
Do not rely on CL’s condition reporting at all for Shen user-facing errors.
The only stable strategies are:
suppress CL reporting completely at the point of signaling (custom non-reporting conditions), or
never re-signal inside a handler — unwind first, then report once, yourself.
Anything else is fighting the spec and the implementation.
So yes: you’re not missing a trick — you’ve found a genuine impedance mismatch between Shen’s needs and CL’s error machinery.
. No version number change since the revisions were done--
You received this message because you are subscribed to the Google Groups "Shen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+un...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/qilang/cf05d783-545a-4ea9-8dbf-a3e479ba8b29n%40googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/qilang/0e835a00-3df0-4745-bc4a-ed4c9c6f9d02n%40googlegroups.com.