This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Confusing error message


On 04/16/2011 11:58 AM, Charles Turner wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/04/11 18:24, Per Bothner wrote:

I added the empty list type to Scheme, along with an inexact type which
I noticed was missing.

I don't think that is right - inexact isn't a type, but a property of a type.


Technically the "integer" type should probably be renamed "exact-integer"
- that would be more compatible with R6RS and the just-released R7RS draft.


Type checking seems to be a mixed bag in Kawa, most of the time the type errors seem to emanate from a ClassCastException, which seems quite elegant. I'll have to look into why cdr doesn't do it like this, but when I find out why, would it be okay to try and make it use the ClassCastException as well?

I think so.


The black sheep however now has this behaviour,

#|kawa:1|# (cdr '())
Argument #1 '()' to 'cdr' has wrong type (empty-list)

and the currently not-yet-fixed ClassCastException ones (the majority)
pick up the EmptyList type,

Good - that seems an improvement!


#|kawa:3|# (cddr '())
Invalid parameter, was: gnu.lists.EmptyList cannot be cast to gnu.lists.Pair

so when I fix it to pick up language independent types, it'll read more
like the first example.

Sounds good.


I was thinking about the expected types bit, it seems that such
information is hard-wired into the code, passed by the programmer
manually as strings,

Usually, the expected type is a gnu.bytecode.Type of some kind, and that is preferred. Sometimes that is tricky, so the expected type is just a string, which isn't really what we want.

would it be feasible to make some sort of massive
hash mapping procedures to a list of their types? Allowing users to type
their own programs might get too hairy, but having a type hash for the
"core forms" might be quite useful internally. Then when you wanted to
inform the user of the expected type, you could index into the
procedures "type list" and pull it from there.

I prefer not. Mostly Kawa looks at the Java method signature, and maps that into language types. Mostly that works, but isn't quite right. Better would be to use java.lang.reflect.Method#getGenericParameterTypes, but that seems non-trivial. Alternatively, one could use an annotation.

About your patch: Mostly good, but some concerns:

In WrongType, it might be good to make the code more robust in case currentLang
is null. Perhaps:


      Type wrongTypeName = argValue.getClass().getName();
      sbuf.append(" (");
      sbuf.append(argValue.getClass().getName());
      if (currentLang == null)
        sbuf.append(wrongTypeName);
      else
        sbuf.append(currentLang.formatType(Type.getType(wrongTypeName)));

In PairWithPosition.java:
+   * An encoding of <code>(lineNumber << 12) + columnNumber</code>

You're write that the old comment was wrong. Ooops. But it would be better to use
the {@code ...} JavaDoc syntax, since <<code> doesn't solve the problem with the <<:


* An encoding of {@code (lineNumber << 12) + columnNumber}

Also, the comment for writeExternal seems to have the same problem.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]