libera/#commonlisp - IRC Chatlog
Search
4:12:31
beach`
I need some ideas. Let's say I have a library L that implements some part of the standard, and let's say some Common Lisp implementation C wants to use the library intrinsically, i.e., C does not have its own code for what L implements.
4:12:37
beach`
Now, when some code in L detects an error situation, it needs to signal an error, and sometimes the error condition type is not standardized. But if L defines its own condition types to signal, then the error will be reported in terms of L, and perhaps that situation is not appealing to C.
4:12:38
beach`
So I need a way for C to parameterize what condition types L will use in order to signal errors. How can this be done in a way that is not too hard to do or to understand?
4:16:22
beach
So I guess I need for some names of condition types to have a package determined by C, and then referenced (perhaps indirectly) by L when an error situation occurs.
4:20:27
edwlan[m]
Would it make sense to have the implementation handle the conditions the library provides and signal its own condition?
4:21:03
beach
That would certainly work. But I fear that this mechanism would be too complicated. But maybe not. Perhaps a macro could help.
4:22:18
beach
I guess in some cases for C to establish a condition handler for some function in L would be too expensive.
4:26:10
beach
How about this: L defines a generic function ERROR with one required parameter. It also defines it's own condition types. By default L:ERROR calls CL:ERROR, so that if C does nothing, something reasonable happens.
4:26:10
beach
But C can define a method (EQL specialized to the required parameter with the object being a symbol in L) that calls CL:ERROR using some condition type defined by C itself.
5:31:02
beach
You are probably right. However, in the case of re-signaling, the cost is paid on every call, whether it signals anything or not. In the case of the generic function, the cost is paid only when an error is signaled. And error signaling is usually not cheap, so the cost is drowned by the rest of the processing.
6:08:32
jackdaniel
beach: how about a generic function (client-condition client l-condition) that defaults to identity?
6:11:27
beach
The difference would be in how additional arguments are treated. In this suggestion, they are all passed to the client condition creation.
6:15:14
jackdaniel
this solution is more failproof. imagine someone calling l:error with an instance (not a symbol) created earlier (i.e resignaling)
10:10:52
Equill
beach: in case you haven't already found a viable solution, I have a hacky workaround that _may_ do what you need. Have L create a LUT when it's loaded, that C can override. The LUT's keys are identifiers for problems that need signalling, and the values are the conditions to be signalled.
10:12:05
beach
Equill: Thanks. Aside from the implementation, I think the solution is similar to the one I suggested.
10:12:09
Equill
The obvious catch is that any conditions C inserts into the LUT will need to accept the same parameters as the conditions they're replacing. Otherwise, I *think* the only run-time-overhead is the look-up involved when the condition is signalled.