On 8/23/16 Aug 23 -9:55 AM, Elias Pipping wrote:
On 23 Aug 2016, at 15:50, Robert Goldman rpgoldman@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