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

[Faré]

On Thu, Sep 1, 2016 at 10:50 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> On 9/1/16 Sep 1 -7:40 PM, Faré wrote:
>>> For the user, the important information is "why is this not supported?"
>>> > and that has to do with static information the programmer should supply,
>>> > rather than with information about what the current information is.
>>> >
>> My contention is that the programmer cannot supply this information.
>> Certainly not in a maintainable way.
>
> I'm sorry, I simply do not understand this claim.
>
> Here is my counter-example, in your "handwriting," as it were:
>
> #-(or abcl allegro clasp clisp clozure cmucl cormanlisp digitool ecl gcl
> genera lispworks mkcl sbcl scl xcl)
>     (error "~S not implemented on ~S" 'delete-empty-directory
> (implementation-type))) ; genera
>
> This seems to be exactly an example of what I'm claiming, and the error
> call you wrote could be replaced with
>
> (error 'unsupported-functionality
>    :functionality 'delete-empty-directory
>    :reason "not supported on ~a" :reason-args (list (implementation-type)))
>
I was wrong then. It would always be "not supported on ~a",
and yet it would always be wrong: one release later (if Genera is ever
released again),
the thing would be completely false and the message should have been
"please upgrade your Genera installation, contact David K. Schmidt".
Until DKS isn't the guy anymore, and then the message is wrong again.

Just the name of the unimplemented thing should be all.

> Similarly, I have often written a first draft of a system using
> Allegro's EXCL.OSI filesystem utilities, and then replaced it with a
> portable version later.
>
> (error 'unsupported-functionality
>         :functionality <foo>
>         :reason " relies on ACL-specific mktemp function.")
>
This is not a helpful or maintainable error message.
There's no action the user can take based on the extra information in
that message.

> There are lots of systems out there, at least some of whose
> functionality relies on other implementation-specific information.
>
That's fine. Just throw an error on other implementations.
Someone who wants to fix it will have to edit the source code,
at which point you can have much more information in the code itself,
including comments.

> In that case yes, I as a programmer definitely DO know that it is not
> supported because I didn't bother to use other than Allegro-specific
> functions.
>
If you edit the source code, you don't need that message.
If you don't edit the source code, you don't need that message.
No one needs that message.

If you want, the generic message could explain that this version of ASDF
doesn't support this functionality on this version of the implementation.
Still both obvious to a programmer and not helpful.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
To those who ask "why would anyone want to write free software for free?",
I answer: "why would anyone want to write a PhD thesis?" — Faré