[Sbcl-help] improving error messages for concatenate

[Faheem Mitha]

Hi,

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

Traceback

The value "foo"
is not of type
(OR CONS SYMBOL SB-KERNEL:INSTANCE).
[Condition of type TYPE-ERROR]

Restarts:
0: [RETRY] Retry SLIME REPL evaluation request.
1: [*ABORT] Return to SLIME's top level.
2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
RUNNING {C208B11}>)

Backtrace:
0: (CONCATENATE "foo" "bar")[:OPTIONAL]
1: (CONCATENATE "foo")[:EXTERNAL]
2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CONCATENATE "foo" "bar")
#<NULL-LEXENV>)
3: (EVAL (CONCATENATE "foo" "bar"))
--more--

This message gives no indication that the user has got it nearly correct,
namely that is should have been

(concatenate 'string "foo" "bar")

so, needs to include a type specifier. Also, this is not really consistent
with the error for the list case, which actually is a much better error
message.

CL-USER> (concatenate (list 1 2) (list 3 4))
; Evaluation aborted on #<SIMPLE-ERROR "bad thing to be a type specifier:
~S" {C15AE29}>.

bad thing to be a type specifier: (1 2)
[Condition of type SIMPLE-ERROR]

Restarts:
0: [RETRY] Retry SLIME REPL evaluation request.
1: [*ABORT] Return to SLIME's top level.
2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
RUNNING {C208B11}>)

Backtrace:
0: (SB-KERNEL:VALUES-SPECIFIER-TYPE (1 2))
1: (SB-KERNEL:SPECIFIER-TYPE (1 2))
2: (CONCATENATE (1 2) (3 4))
3: (CONCATENATE (1 2))[:EXTERNAL]
4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CONCATENATE (LIST 1 2) (LIST 3 4))
#<NULL-LEXENV>)
5: (EVAL (CONCATENATE (LIST 1 2) (LIST 3 4)))

If anyone wants me to, I can report this as a bug.

Regards, Faheem

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sbcl-help mailing list
Sbcl...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

[Pascal J. Bourguignon]

Faheem Mitha <fah...@faheem.info> 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 {}.

[Faheem Mitha]

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

[Nikodemus Siivola]

On 13 May 2012 11:02, Faheem Mitha <fah...@faheem.info> 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

[Faheem Mitha]

On Sun, 13 May 2012, Nikodemus Siivola wrote:

> On 13 May 2012 11:02, Faheem Mitha <fah...@faheem.info> 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

[Pascal J. Bourguignon]

Faheem Mitha <fah...@faheem.info> 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 {}.

[Faheem Mitha]

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

> Faheem Mitha <fah...@faheem.info> 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