Robert P. Goldman rpgoldman at
Mon Aug 1 01:52:07 UTC 2016

On 7/31/16 Jul 31 -6:12 PM, Faré wrote:
> On Fri, Jul 29, 2016 at 9:41 AM, Robert P. Goldman <rpgoldman at> 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 at> 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.


More information about the asdf-devel mailing list