Confusing error message

[Per Bothner]

On 04/14/2011 12:36 PM, Charles Turner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Consider this interaction,
>
> #|kawa:1|# (cdr '())
> Argument #1 (()) to 'cdr' has wrong type (gnu.lists.LList)
> <snip stack trace>
>
> Saying the argument was (()) seems wrong, and in cases not as trivial as
> this, I can imagine it being confusing, more cdr'ing gives less
> ambiguous errors,
>
> #|kawa:2|# (cddr '(()))
> Invalid parameter, was: gnu.lists.LList cannot be cast to gnu.lists.Pair
> <snip stack trace>

I see 3 issues:

(1) Why are the error messages so different?  I haven't really looked at 
that.
It may be harder to fix than the other issues.

(2) We should be using "Scheme names" for types in error message, rather
than raw Java class name.  E.g. "pair" and "list" rather than 
"gnu.lists.Pair"
and "gnu.lists.LList".  Kawa has a mechanism for this: It has the method
Language#formatType, which takes a type and returns a 
language-appropriate name.
So the error messages above should be fixed to use formatType, as is used in
various the places.  It may have to dynamically look for the "current 
Language"
or it could use the "language used to compile the current class".

(3) Ideally, you'd want "Argument #1 (()) to 'cdr' has wrong type (empty 
list)"
(or perhaps (empty-list) to avoid the space in the middle of a "type name").
This could be done most easily by creating a Singleton class 
gnu.lists.EmptyList
that contains just LList.Empty.

(4) The extra parentheses is confusing, I agree.  Clearer would be:
Argument #1 to 'cdr' (whose value is: ()) has wrong type (gnu.lists.LList)
The outer parens are in the "English language aside" sense, not the 
"Lisp" sense.
Better formatting would be welcome, but try to keep it terse.
Using single quotes as you suggest may also be a good choice.
Ideally, something like this perhaps:
'cdr' called with argument #1 (value: (), type: empty-list) but expected 
'pair'
(The "expected 'pair'" is a bit trickier with generic or overloaded 
functions.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/