Version 188.8.131.52 has been pushed
elias.pipping at fu-berlin.de
Tue Aug 23 14:55:25 UTC 2016
> On 23 Aug 2016, at 15:50, Robert Goldman <rpgoldman at sift.net> wrote:
> On 8/23/16 Aug 23 -6:42 AM, Elias Pipping wrote:
>> If we can agree on Robert’s unsupported-functionality error class, I’ll work that into the merge request, too.
> I have a busy day today, but I will try to get it done.
> I was thinking of having slots for:
> - implementation
> - capability name
> - optional format control and format args that the programmer can use to
> provide additional information. E.g., for LW, say that it's for
> licensing reasons that the DELIVER capability is not available.
> If this sounds reasonable, I'll put it in, and try to find places it
> should be used.
> In an earlier email, Elias points out that there are related reasons why
> a function might have failed. I haven't had time to figure out whether
> these would call for additional condition classes.
I was thinking: We’re trying to tell the user that what they’re doing does not work. Yes, the function does exist, you’re passing the right number of arguments and the right keywords but there’s a problem. The problem could be:
- Your lisp is very old or very new or nobody’s gotten around to looking into it, so even though your lisp might provide the necessary functionality, the wrapper hasn’t been made to cover it yet (that’s what the master branch currently uses (error “not implemented: ~S” #’function-name) for)
- You’re passing a combination of parameters that is not supported on this lisp (that’s what the master branch currently uses (assert) for)
- The function or combination of parameters you’re calling it with is affected by a known bug on your lisp that we cannot work around.
I was thinking that to the user, it does not make a difference which one of those three reasons a function call fails for, so we could use one condition for all three, and unsupported-functionality captures the concept pretty well.
The capability name would often have to be a rather long description than just a name this way, though, I’m afraid. I’m not sure if I understand the purpose behind the ‘implementation' key of the condition. If a feature is e.g. missing on lisp A and B, and you’re on lisp A, if would simply contain “A”? Or would it contain something like “A personal edition prior to version 2.5?”
More information about the asdf-devel