On 7/31/16 Jul 31 -6:12 PM, Faré wrote:
On Fri, Jul 29, 2016 at 9:41 AM, Robert P. Goldman rpgoldman@sift.info wrote:
On 7/28/16 Jul 28 -10:47 PM, Faré wrote:
On Thu, Jul 28, 2016 at 5:08 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Hmmmm..... Actually, SERIOUS-CONDITION, as I read its documentation, is exactly the right abstraction -- it's just that CCL has broken it:
"All conditions serious enough to require interactive intervention..."
I don't want to export a new concept that is "Like SERIOUS-CONDITION, except patched for an implementation."
I'll fix this internal to ASDF and leave it at that. Some day I hope that FATAL-CONDITION will wither away.
By that token, all of UIOP would be private, hoping that someday the CL standard would fix pathnames, etc.
The whole point of UIOP is to provide ASDF and other CL programs with portability abstractions that actually work in the current CL landscape. Not to pretend that that CL landscape magically matches some imagined ideal when that isn't the case.
I think that's a stretch in this one case -- all the implementations agree on CL:SERIOUS-CONDITION, with the exception of CCL, and I believe they agree that they have simply made a mistake in their implementation.
I'm reluctant to build into UIOP a new type definition whose description exactly parallels the definition of SERIOUS-CONDITION in the spec.
Until now we have limited ASDF and UIOP to plugging holes in the spec (like the absence of good enough pathname support). We haven't been also adding a shadow implementation of the spec for cases where the implementations simply got it wrong. That feels like mission-creep to me.
The closest I'd be willing to go is to remove UIOP:*FATAL-CONDITIONS* and replace it with a type definition for UIOP:FATAL-CONDITION. But even that makes me feel bad. I guess we can keep this for now, but I'll be a lot happier when it's simply an alias for CL:SERIOUS-CONDITION.
Best, R