On Sun, 13 May 2012, Pascal J. Bourguignon wrote:
> Faheem Mitha <faheem@...> 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
|