Re: Confusing error message

[Charles Turner <chturne at gmail dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/04/11 03:28, Per Bothner wrote:
> Kawa has a mechanism for this: It has the method
> Language#formatType, which takes a type and returns a
> language-appropriate name.

This doesn't seem right from my rather brief investigation, the
formatType method calls Type#getName which returns a fully qualified
name, what we don't want. I verified this just to make sure the comment
in Type wasn't erroneous, it returns the same name as
Object.getClass().getName() does in WrongType.

> So the error messages above should be fixed to use formatType, as is
> used in various the places.  

I've noticed the Scheme class uses it, but I suspect such error messages
will have the same shortcoming, like

#|kawa:1|# (map 1 '(1 2 3))
Argument  '1' to 'apply-to-args' has wrong type (gnu.math.IntNum)
(expected: procedure)

where gnu.math.IntNum is fully qualified, it would be nicer to have
integer instead.

The "procedure" text there is hard-wired in, which doesn't seem like a
good design choice (if I may say so myself, eek), I don't know whether a
solution to that would involve some sort of type inference and thus be
beyond someone who struggles to even spell type thory.

I've also found some holes in argument checking, which I'll put on my
todo list, such as,

#|kawa:2|# (map '(1 2 3) '(1 2 3))
java.lang.IndexOutOfBoundsException

I'd prefer Kawa to say something like "expected a procedure but was
given a list", embellished to taste, of course.

> It may have to dynamically look for the "current Language"
> or it could use the "language used to compile the current class".

Don't understand this at the moment, need to look into how this all
works a little further.

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

That makes sense to me, though I refrained from going ahead and doing it
before I understand how the type information is passed around, at the
moment it seems that this infrastructure might need to changed quite a bit.

> The outer parens are in the "English language aside" sense, not the
> "Lisp" sense.

I figured, but it seems like a strange choice when presenting
information for Lisp-like languages, might just be me though, even if I
see something like "(blah blah wrong argument ())" the last bit just
screams at me.

> 'cdr' called with argument #1 (value: (), type: empty-list) but expected
> 'pair' (The "expected 'pair'" is a bit trickier with generic or overloaded
> functions.)

I like that, I probably don't fully appreciate the implications of the
parenthesised comment. However, it seems there's a lot of information in
LangObjType that isn't being used throughout Kawa, viz, the cdr example.
There are various calls to LangObjType#coerceFromObject which should get
the language dependent type names, that's what cdr's of the form cdd...r
do, but for some reason, cdr doesn't. Further investigation on my part
is needed to better respond to that.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJNqHkXAAoJEG9M6fiX7bE402QH/3V/PMklZ8JBvpkMo19+QsHg
jvmCe5e2EF5BEgqVTp1WhgAhfQvrXJRAN21WyVyEk5FNvdJkw2E1kxHanS2DZJCY
2oKlrvNsygURut4Em7cFHx8DSO8/rNl2B0ox8r0NOmlnJmGrJDbYvf7csxTX1xbX
b65tjJv1cTEvBqTnBxSN4M8oHOZz2DLfFqY4qjuw5UND+8LpWXp62TZzv70UPTaY
XhqSpxt17YuQL0ICeYMBLL8wodViCRPQEVBWv2U/gj+zbkaBdeOiVtHTRBtKOWJH
baIYe+Ne2y6rGfvYLO0EAM24Pg+h1npX04ffNT9IjS5bWhkBXARqabkTlpJfOK4=
=QErJ
-----END PGP SIGNATURE-----