Re: [Sbcl-help] improving error messages for concatenate

[Faheem M. <fa...@fa...>]

On Sun, 13 May 2012, Pascal J. Bourguignon wrote:

> Faheem Mitha <fa...@fa...> writes:
>
>> I don't know if the SBCL developers are interested in this sort of thing.
>> It may be too trivial. But, consider...
>>
>> CL-USER> (concatenate  "foo" "bar")
>> ; Evaluation aborted on #<TYPE-ERROR expected-type: (OR CONS SYMBOL
>> SB-KERNEL:INSTANCE) datum: "foo">.
>
> It may be trivial but it represents a lot of work:
>
> 1- it's not limited to concatenate of course.  Each operator in CL would
>   benefit from newbie friendly error reporting.
>
> 2- it's not limited to sbcl all implementations do the same thing.
>
> Namely, they defer most of the type checking (and in general, parameter
> validation), to the lower level functions called.  This is sound lisp
> engineering since this avoid testing for the types/validity of the
> parameter at each function call.  But indeed it has the defect that the
> errors are not detected early and in the most meaningful context.  It
> has also the problem that implementation details changing, the exact
> error reported is not the same from one implementation to another.  This
> is related to the fact that very few CL operators are defined to signal
> specific conditions (at very few and coarse conditions are defined).
>
>
> There's matter for a nice CDR here:
>
> - specifying a complete ontology of conditions for the CL package.
>
> - specifying precisely for each CL operator, what condition should be
>  signaled in what situation.
>
>
> So, passing a string instead of a sequence type as first argument of
> concatenate is indeed a type error (that's what most implementations
> signal, ccl signals a subclass of program-error and allegro a subclass
> of error (all are confomring:
>
>    An error is signaled if the result-type is neither a recognizable
>    subtype of list, nor a recognizable subtype of vector.
>
> )), but the CDR could specify a more precise condition, a subclass of
> type-error that would report exactly the newbie-friendly meaning:
>
>
> (define-condition sequence-type-expected-error (type-error)
> ((function  :initarg :function  :reader sequence-type-expected-error-function)
>  (parameter :initarg :parameter :reader sequence-type-expected-error-parameter)
>  (datum     :initarg :datum     :reader sequence-type-expected-error-datum))
> (:report (lambda (err stream)
>             (format stream
>                    "Function ~A expected a subtype of sequence ~
>                     in its ~:R parameter, instead it got the ~A ~S"
>                    (sequence-type-expected-error-function err)
>                    (sequence-type-expected-error-parameter err)
>                    (type-of (sequence-type-expected-error-datum err))
>                    (sequence-type-expected-error-datum err)))))
>
>
> So:
>
> 1- you'd get this error message:
>
>        Function concatenate expected a subtype of sequence in its first
>        parameter, instead it got the (simple-base-string 3) "Abc"
>
> 2- programs could recover more precisely from errors signaled by CL
>   operators.
>
>
> But again, the same work has to be done for all the CL operators (and
> hopefully implemented by all implementations).

Hi Pascal,

Thanks for the reply, and the detailed explanation. I should have guessed 
that there was some reason the errors showed up this way. Does this mean 
the SBCL developers are not interested in comments about error messages? I 
don't want to spam the list pointlessly. I ask since I've seen SBCL errors 
which much more obscure than this, and might comment on them on this list 
as I came across them. They are still much better than, for example, C++ 
template error messages, though.

BTW, what does CDR mean? The first thing that comes to mind is "something 
Defect Report", but that doesn't quite fit.

Also, I don't get the significance of

> Reading of: "(concatenate \"Abc\" \"def\")"
> signaled no error

Can you elaborate? Please excuse my ignorance.

                                                            Regards, Faheem