Steel Bank Common Lisp

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).



[pjb@... :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@... :0 ~]$ 

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

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

On 13 May 2012 11:02, Faheem Mitha <faheem@...> wrote:

> 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

Yes, we are. They're a low priority mostly, though, but they're also
excellent introductory tasks for people new to SBCL hacking.

Launchpad is a better place for them than this list, though.

  https://launchpad.net/sbcl

If you don't want to get a Launchpad userid, you can also send mail to
sbcl-bugs, which doesn't require subscription. (Reporting directly to
Launchpad is much preferred, though -- less work for us.)

Cheers,

 -- Nikodemus

On Sun, 13 May 2012, Nikodemus Siivola wrote:

> On 13 May 2012 11:02, Faheem Mitha <faheem@...> wrote:
>
>> 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
>
> Yes, we are. They're a low priority mostly, though, but they're also
> excellent introductory tasks for people new to SBCL hacking.
>
> Launchpad is a better place for them than this list, though.
>
>  https://launchpad.net/sbcl
>
> If you don't want to get a Launchpad userid, you can also send mail to
> sbcl-bugs, which doesn't require subscription. (Reporting directly to
> Launchpad is much preferred, though -- less work for us.)

Hi Nikodemus,

Yes, I've got a Launchpad account. I even reported one SBCL bug there; 
which you fixed. Ok, I'll direct such comments there in the future.

                                                       Regards, Faheem

Faheem Mitha <faheem@...> writes:

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

CDR - Common Lisp Document Repository
http://cdr.eurolisp.org/

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

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

> Faheem Mitha <faheem@...> writes:
>
>> BTW, what does CDR mean? The first thing that comes to mind is
>> "something Defect Report", but that doesn't quite fit.
>
> CDR - Common Lisp Document Repository
> http://cdr.eurolisp.org/

Oh, I see. A repository for proposed standard documents. Interesting. But 
quiet.

                                                           Regards, Faheem