UNSUPPORTED-FUNCTIONALITY Error [was Re: Version 3.1.7.7 has been pushed]

[Robert P. Goldman]

You are ignoring my proclaimed purpose of improving the testing of ASDF. 

Sent from my iPhone

> On Aug 25, 2016, at 22:21, Faré <fahree at gmail.com> wrote:
> 
> I'd rather keep it simple.
> 
> End-users don't care WHY something is failing, just THAT it is failing
> gracefully and that the reason for failure is known. Users
> (programmers) can use M-. from the error to find the source and
> comments. A short link to a suitable cliki.net page might help explain
> the proper investigation procedure.
> 
> I see no reason for some programmer-intensive protocol that leads to
> large image size increase for no clear benefit that M-. won't bring.
> 
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> Those "organizers" who confuse coordination and cooperation will have 100%
> coordination for 0% cooperation. All costs, no benefits.
> 
> 
>> On Thu, Aug 25, 2016 at 10:37 PM, Robert Goldman <rpgoldman at sift.net> wrote:
>>> On 8/23/16 Aug 23 -9:55 AM, Elias Pipping wrote:
>>> 
>>>> 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?”
>> 
>> I was focusing on the implementation, and perhaps a version number,
>> because I have mostly been thinking about how I would use this new error
>> class in the tests. In particular, I was thinking of running the tests
>> on all lisp implementations, and catching expected failures, rather than
>> doing what we do now, which is disable the tests on platforms where we
>> believe a function is not available.
>> 
>> If we were to run tests on all implementations/platforms, and catch
>> expected errors, that would help us detect unexpected successes, when
>> functionality that used to be broken starts to work.
>> 
>> Well, I have also been thinking about how nice it would be to have an
>> understandable, standard error message for users who use an unsupported
>> function by accident.
>> 
>> What about:
>> 
>> 1. Capability -- what we were trying to do.
>> 2. Implementation name -- string, or could be a keyword, if we were to
>> add a list of keywords.
>> 3. Optional version number
>> 4. Optional platform (for, e.g., "this works on SBCL > 1.2, but not on
>> Windows.")
>> 5. Additional information (e.g., LW personal edition)
>> 
>> We could have a signal-unsupported-capability function that would
>> auto-collect some of these slot values, to make this easier to use.
>> 
>> There's no tearing hurry for this, so I'm happy to have some more email
>> cycles so that we can get it right.
>> 
>> Best,
>> r
>