On 04/11/15 09:59, Mark Evenson wrote:
On 2015/4/8 20:13, Massimiliano Ghilardi wrote: […]
Only I am surprised that LispObjects can be null: is it allowed, and when can it happen?
As far as I can determine, LispObject references should never be null when being passed as an argument to a Java function, but the code base is inconsistent (buggy) on this point.
Understood.
As for your question on "whether ABCL is really supposed to pass null LispObject references to the Java implementation of primitive types", I think the answer is negative, as a Java primitive type by definition cannot hold a null reference. This disjunction from java.lang.Object is what "makes" it a primitive type. Our codebase is riddled with the assumption that accessing a LispObject won't return a null, as in the location your [test case failed][1]:
if (!value.equalp(ht.get(key))) { return false; }Here, ht.get() should not return a null reference to be chained into the value.equalp() call no matter what the value of 'key' turns out to be. In lieu of something like a comprehensive audit, we are unfortunately left fixing these problems on a case by case basis.
From what I saw, ht.get(key) returns Java null if key is not present in the hash-table. I agree this is a case of "the code base is inconsistent (buggy) on this point".
On the other hand, let me change my mind and tell this: I find it non-obviously useful, although contorted. Since Java null is not a valid LispObjects, it can represent "failure", as in the case "key not present in hash-table", without having to use multiple values.
For example, for a EQUALP hash-table, "value.equalp(ht.get(key))" exactly means "hash-table ht contains the pair key/value"
If ht.get(key) is modified to return a valid LispObject (for example NIL) to mean "key not found", the code "value.equalp(ht.get(key))" will become bugged for value == NIL. Fixing it requires ht.get(key) to return multiple values. The code "value.equalp(ht.get(key))" would become more complicated, probably something like:
LispObject v = ht.get(key); LispThread.currentThread().getValues()[1] != NIL && value.equalp(v);
But perhaps I have misunderstood your question somewhat: is there something more specific you were referring to?
I was asking the same question you already answered above.
Just I realize "primitive types" is misleading, as I meant "types defined by the Common Lisp standard and implemented in Java by ABCL", not "Java primitive types".
Regards,
Max