Re: The nature of truth

[Jim White <jim at pagesmiths dot com>]

Per Bothner wrote:
> Jim White wrote:
>
> > Those are just the two changes I had in mind, but didn't have time to 
> > track down where they went.  With those changes Kawa is entirely 
> > consistent with itself (and sensible Java practice).  It is easy to 
> > see why boolean? appears to map to 'instance? <java.lang.Boolean>', 
> > but for the reasons already discussed, that relationship doesn't hold.
>
> The question is:  What should standard Scheme functions do on values 
> that are proper Scheme values?  And more specifically what should Scheme 
> type predicates do?
>
> Consider (symbol? x).  It is implemented as (instance? x 
> <java.lang.String>).
> ...

Kawa's treatment of j.l.String and symbol? with uninterned symbols is 
entirely reasonable and is consistent with traditional Lisp usage.  This 
sort of implementation is even described explicitly in the spec:

http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%25_sec_6.3.3

So I don't thing any change is called for there.

> I don't see any reason for Chris's change to DisplayFormat.writeObject. 
>  What if the parameter is a non-canonical boolean?  We have to do 
> something with them.  "Coercing" them to boolean may not be 100% 
> consistent, but you're not going to get 100% consistency if you use 
> non-canonical booleans, and the existing behavior seems as good a choice 
> as any.

But the point is if a non-canonical j.l.Boolean happens to arise, it 
shouldn't at the "last minute" be treated as canonical and be displayed 
as one.  In other words, #f should only appear for an object that is 
'eq? #f'.

And pragmatically, for the poor soul who encounters a non-canonical 
j.l.Boolean, they'll have a visible sign of the problem.

> The change to boolean? is more plausible.  The performance difference is 
> minor, and given that in Scheme any value can be used as a boolean, it 
> may be reasonable to defined boolean? as testing for "canonical boolean".

I believe that is a sufficient argument for the display change as well 
(#f and #t display iff boolean?).

I did a search for 'booleanValue', and it appears to me that Kawa is 
fairly consistent in its usage except for these two cases.  Everywhere 
else the coercion to canonical boolean seems to only occur for primitive 
booleans.  Nowhere else does it try to use booleanValue for 
non-canonical j.l.Boolean.

Things are a bit murkier with the newer XQuery stuff.  It's BooleanValue 
stuff *does* appear to always handle j.l.Boolean by value.  I'm not sure 
of the reason for that.  I'm assuming it might be because you expect it 
to be used with external Java code somehow?  I don't think that is a 
really good direction to go, as it doesn't seem to be good for Scheme or 
Java.

Jim
--
"I love deadlines. I love the whooshing sound they make as they fly by." 
-- Douglas Adams