libera/#commonlisp - IRC Chatlog
Search
20:30:04
zyd
Has anyone got lem to successfully install and run via roswell? If so could you tell me what SBCL version you are running.
21:26:36
jeosol
danisanti: have you resolved your issue yet? Like random-nick and gilberth suggested, it's not possible.
21:27:21
jeosol
danisanti: perhaps, depending on what you are trying to do, you may serialize the objects to file and load them into a running session.
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)