strange int->boolean behavior

strange int->boolean behavior

[Jamison Hope]

Sometimes, a primitive 0 is false:

#|kawa:1|# (->boolean (->int 3))
Exception in thread "main" java.lang.Error: unsupported CodeAttr.emitConvert
	at gnu.bytecode.CodeAttr.emitConvert(CodeAttr.java:2006)
	[...]

#|kawa:1|# (if (->int 3) "YES" "NO")
YES
#|kawa:2|# (if (->int 0) "YES" "NO")
YES
#|kawa:3|# (define (f x::int) ::string (if x "YES" "NO"))
#|kawa:4|# (f 3)
YES
#|kawa:5|# (f 0)
NO
#|kawa:6|# (disassemble f)
In class atInteractiveLevel$3

Method name:"f" public static Signature: (int)java.lang.CharSequence
Attribute "Code", length:70, max_stack:1, max_locals:1, code_length:14
  0: iload_0
  1: ifeq 10
  4: getstatic <Field atInteractiveLevel$3.Lit0 java.lang.String>
  7: goto 13
 10: getstatic <Field atInteractiveLevel$3.Lit1 java.lang.String>
 13: areturn

I get similar results with the other primitive types.  If I'm following things correctly, it's ConditionalTarget#compileFromStack which is treating zero as false?

--
Jamison Hope
The PTR Group
www.theptrgroup.com

Re: strange int->boolean behavior

[Per Bothner]

On 12/18/2014 10:19 AM, Jamison Hope wrote:
> Sometimes, a primitive 0 is false:
>
> #|kawa:1|# (->boolean (->int 3))
> Exception in thread "main" java.lang.Error: unsupported CodeAttr.emitConvert
> 	at gnu.bytecode.CodeAttr.emitConvert(CodeAttr.java:2006)
> 	[...]
>
> #|kawa:1|# (if (->int 3) "YES" "NO")
> YES
> #|kawa:2|# (if (->int 0) "YES" "NO")
> YES
> #|kawa:3|# (define (f x::int) ::string (if x "YES" "NO"))
> #|kawa:4|# (f 3)
> YES
> #|kawa:5|# (f 0)
> NO
> #|kawa:6|# (disassemble f)
> In class atInteractiveLevel$3
>
> Method name:"f" public static Signature: (int)java.lang.CharSequence
> Attribute "Code", length:70, max_stack:1, max_locals:1, code_length:14
>    0: iload_0
>    1: ifeq 10
>    4: getstatic <Field atInteractiveLevel$3.Lit0 java.lang.String>
>    7: goto 13
>   10: getstatic <Field atInteractiveLevel$3.Lit1 java.lang.String>
>   13: areturn
>
> I get similar results with the other primitive types.  If I'm following things correctly,
>it's ConditionalTarget#compileFromStack which is treating zero as false?

Yes. I checked in a fix for this.  The change in ConditionalTarget depends on the language;
specifically whether language.isTrue(Integer.valueOf(0)).  If so, we an just
emitGoto the true label.

I forgot about or overlooking this message, but found it while searching for
another discussion (which turn out to be "proposed changes to handling of false
and end-of-list").

(I'm looking into doing at least part of that previous proposal - specifically
treating #!null as false.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: strange int->boolean behavior

[Jamison Hope]

On Feb 19, 2015, at 6:03 PM, Per Bothner <per@bothner.com> wrote:

> On 12/18/2014 10:19 AM, Jamison Hope wrote:
>> Sometimes, a primitive 0 is false:
>> 
>> #|kawa:1|# (->boolean (->int 3))
>> Exception in thread "main" java.lang.Error: unsupported CodeAttr.emitConvert
>> 	at gnu.bytecode.CodeAttr.emitConvert(CodeAttr.java:2006)
>> 	[...]
>> 
>> #|kawa:1|# (if (->int 3) "YES" "NO")
>> YES
>> #|kawa:2|# (if (->int 0) "YES" "NO")
>> YES
>> #|kawa:3|# (define (f x::int) ::string (if x "YES" "NO"))
>> #|kawa:4|# (f 3)
>> YES
>> #|kawa:5|# (f 0)
>> NO
>> #|kawa:6|# (disassemble f)
>> In class atInteractiveLevel$3
>> 
>> Method name:"f" public static Signature: (int)java.lang.CharSequence
>> Attribute "Code", length:70, max_stack:1, max_locals:1, code_length:14
>>   0: iload_0
>>   1: ifeq 10
>>   4: getstatic <Field atInteractiveLevel$3.Lit0 java.lang.String>
>>   7: goto 13
>>  10: getstatic <Field atInteractiveLevel$3.Lit1 java.lang.String>
>>  13: areturn
>> 
>> I get similar results with the other primitive types.  If I'm following things correctly,
>> it's ConditionalTarget#compileFromStack which is treating zero as false?
> 
> Yes. I checked in a fix for this.  The change in ConditionalTarget depends on the language;
> specifically whether language.isTrue(Integer.valueOf(0)).  If so, we an just
> emitGoto the true label.

Cool, thanks.

> I forgot about or overlooking this message, but found it while searching for
> another discussion

That's OK, I've been too busy lately to bug you about it (and you've obviously
been busy too, since you've made ~100 commits since then).

> (which turn out to be "proposed changes to handling of false
> and end-of-list").
> 
> (I'm looking into doing at least part of that previous proposal - specifically
> treating #!null as false.)

Great!  That will be a welcome change.  Wow, that discussion was a while ago..
there's some good stuff in there (in my perhaps slightly biased opinion).

--
Jamison Hope
The PTR Group
www.theptrgroup.com