One reason Nathan's comment was confusing to me is exactly what you
(Buck) have said. To me, the concept of "never really clear to them
what they may be looking for" is just not applicable.
John,
On the whole, your comments are somewhat confusing to me too. On one hand,
you appear to be interested in sending diagnostic and escape messages to
CLPs from Python. But on the other hand, you say that you don't have the
means of doing that, and that it would take an enormous effort to create
that.
If your goal is for CLPs to receive messages from Python, I'm just
suggesting that you come up with a solution that doesn't involve using
program message queues. The term "program" in this context is something of
a misnomer, because every procedure in a call stack has a message queue
associated with it. The API for "sending" program messages requires that
you specify the call-stack level that you want to send to. Likewise, the
API for receiving messages, also requires that you specify the call-stack
level that you want to receive from. That is a problem, in my opinion.
An operator, or a programmer who is debugging and doesn't yet know
what the problem is, might not be clear on what they're looking for.
Someone purposely putting in code to handle exceptions really ought to
know what exceptions they're handling.
Called programs don't necessarily know what procedures at what call-stack
levels may be receiving their messages. And the call-stack entries that may
need to monitor for messages, are never really assured whether messages
will be sent to their message queue, or to one preceding it, or to one
seceding it.
The idea of having callers implement code to receive messages and percolate
those they don't know how to handle, seems like a kludge to me.
It's not just that the interface is arcane. It's unwieldy and prone to
error, in my opinion. Perhaps given enough custom code, one might be able
to get it to work. But what a hassle.
As an Amazon Associate we earn from qualifying purchases.