cl-test-grid results for svn revision 14755
Massimiliano Ghilardi
massimiliano.ghilardi at gmail.com
Sat Apr 11 13:13:23 UTC 2015
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".
>
> [r14757]: http://abcl.org/trac/changeset/14757
> [1]:
> http://abcl.org/trac/browser/trunk/abcl/src/org/armedbear/lisp/HashTable.java#L150
>
Regards,
Max
More information about the armedbear-devel
mailing list