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.
To view this discussion, visit https://groups.google.com/d/msgid/qilang/d0f2988c-843e-4267-ae75-50afa792a023n%40googlegroups.com.