Misleading error message on "package unknown"

[marcoxa]

The following shows a problem that I noticed.

The condition signalled seems ok (SIMPLE-READER-ERROR) but the associated message does not mention the fact that the problem is the unknown package.

Incidentally I would create a special PACKAGE-NOT-FOUND-READER condition for this specific error.

paniscia:~ marcoxa$ ccl
AM I BEING LOADED?
Welcome to Clozure Common Lisp Version 1.5-r13651  (DarwinX8632)!
? (ignore-errors (read))
foo::bar

NIL
#<CCL::SIMPLE-READER-ERROR #xC47489E>
? > Error: Unbound variable: BAR
> While executing: CCL::TOPLEVEL-EVAL, in process listener(1).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Retry getting the value of BAR.
> Type :? for other options.
1 > :pop

Marco

[gz]

The error message does mention the package being unknown:

? (read-from-string "foo::bar") 
> Error: Reader error on #<STRING-INPUT-STREAM  #x30200076DFDD>, near position 5, within "foo::bar": 
>        Reference to unknown package "FOO". 

In your example, the call to READ signals the error after reading off "foo::", IGNORE-ERRORS catches the error and returns it. That's the #<CCL::SIMPLE-READER-ERROR #xC47489E> you see -- if you princ it, you will see the message about unknown package.

The listener REPL then goes on to read the next from from the input stream, which still contains "bar". The REPL reads it, tries to evaluate it, and gets the second error, unbound variable.

Which mostly goes to show that it's not a good idea to call READ from the listener.

[gb]

In the reader algorithm described in section 2.2 of the spec, an entire token - FOO::BAR in this case - is read before things like package lookup presumably happen. CCL's reader is doing the package lookup as soon as it reads the package markers (e.g., when only part of the token's been read.)

The spec seems to lose interest in describing reader behavior once weighty issues involving potential numbers have been resolved, but I think that deferring the package lookup until a complete token's been read is preferable to CCL's current behavior (where we're basically reading partial tokens.) The spec does describe token collection in excruciating detail, and CCL's current behavior basically introduces an undocumented step in that algorithm. Whether this is correct or not is hard to say, but it's hard to see it as being desirable.