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