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

[Robert P. Goldman]

With all due respect, a few minutes ago you were saying I shouldn't expect to have the source code, in response to my desire to restore some of the source-finding functionality of load truename, but in this message you are telling me it's enough to have simple error objects because everybody has meta-dot to fall back upon. 

So now I find myself arguing for the position you articulated in your last response! With respect to ASDF ( and explicitly as opposed to the case of my DSL, which happens to simply not work if the source code is not present), we know that programmers often have bundled copies of ASDF, provided by vendors without source, and so meta dot does not work. 

Best,
R

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