From: Pascal J. B. <pj...@in...> - 2012-05-13 01:41:00
|
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). [pjb@kuiper :0 ~]$ clall '(concatenate "Abc" "def")' Armed Bear Common Lisp: ======================================================================== Implementation: Armed Bear Common Lisp 1.0.1 on X86-64 Reading of: "(concatenate \"Abc\" \"def\")" signaled no error Evaluation of: (CONCATENATE "Abc" "def") signaled the following error: #<TYPE-ERROR {5585C0DE}> The value "Abc" is not of type SYMBOL. wrote nothing on *ERROR-OUTPUT* wrote nothing on *STANDARD-OUTPUT* returned no value International Allegro CL Free Express Edition: ======================================================================== Implementation: International Allegro CL Free Express Edition 8.2 [Linux (x86)] (Sep 11, 2010 7:36) on x86 Reading of: "(concatenate \"Abc\" \"def\")" signaled no error Evaluation of: (CONCATENATE "Abc" "def") signaled the following error: #<SIMPLE-ERROR @ #x20754a3a> "Abc" is an invalid output type specification. wrote nothing on *ERROR-OUTPUT* wrote nothing on *STANDARD-OUTPUT* returned no value Clozure Common Lisp: ======================================================================== Implementation: Clozure Common Lisp Version 1.8-r15286M (LinuxX8664) on x86_64 Reading of: "(concatenate \"Abc\" \"def\")" signaled no error Evaluation of: (CONCATENATE "Abc" "def") signaled the following error: #<CCL::INVALID-TYPE-SPECIFIER #x3020007EB54D> Invalid type specifier: "Abc" . wrote nothing on *ERROR-OUTPUT* wrote nothing on *STANDARD-OUTPUT* returned no value CLISP: ======================================================================== Implementation: CLISP 2.49+ (2010-07-17) (built 3542867425) (memory 3542867673) on X86_64 Reading of: "(concatenate \"Abc\" \"def\")" signaled no error Evaluation of: (CONCATENATE "Abc" "def") signaled the following error: #<SIMPLE-TYPE-ERROR #x000333FBD7A8> There are no sequences of type "Abc" wrote nothing on *ERROR-OUTPUT* wrote nothing on *STANDARD-OUTPUT* returned no value CMU Common Lisp: ======================================================================== Implementation: CMU Common Lisp 20b (20B Unicode) on X86 Reading of: "(concatenate \"Abc\" \"def\")" signaled no error Evaluation of: (CONCATENATE "Abc" "def") signaled the following error: #<TYPE-ERROR {581F5FCD}> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: "Abc" is not of type (OR CONS SYMBOL EXTENSIONS:INSTANCE) wrote nothing on *ERROR-OUTPUT* wrote nothing on *STANDARD-OUTPUT* returned no value SBCL: ======================================================================== Implementation: SBCL 1.0.55 on X86-64 Reading of: "(concatenate \"Abc\" \"def\")" signaled no error Evaluation of: (CONCATENATE "Abc" "def") signaled the following error: #<TYPE-ERROR expected-type: (OR CONS SYMBOL SB-KERNEL:INSTANCE) datum: "Abc"> The value "Abc" is not of type (OR CONS SYMBOL SB-KERNEL:INSTANCE). wrote nothing on *ERROR-OUTPUT* wrote nothing on *STANDARD-OUTPUT* returned no value ======================================================================== [pjb@kuiper :0 ~]$ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |