#t and #f now default to primitive types

#t and #f now default to primitive types

[Per Bothner]

The literals #t and #f are now treated as having primitive boolean types,
rather than java.lang.Boolean type.  That is the return type of:

     (define (neg x) (if (>= x 0) #f #t))

is boolean rather than java.lang.Boolean.

Of course you can specify Boolean explicitly if you want:

     (define (neg x) ::java.lang.Boolean (if (>= x 0) #f #t))
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: #t and #f now default to primitive types

[Jamison Hope]

On Apr 2, 2015, at 9:27 PM, Per Bothner <per@bothner.com> wrote:

> The literals #t and #f are now treated as having primitive boolean types,
> rather than java.lang.Boolean type.  That is the return type of:
> 
>    (define (neg x) (if (>= x 0) #f #t))
> 
> is boolean rather than java.lang.Boolean.
> 
> Of course you can specify Boolean explicitly if you want:
> 
>    (define (neg x) ::java.lang.Boolean (if (>= x 0) #f #t))

Thanks, Per.  I find it curious that with neg defined as above
(returning primitive boolean), these return what they do:

(define (f a b) (and (neg a) (neg b)))
(define (g a b) (if (neg a) (neg b) #t))
(define (h a b) (or (neg a) (neg b)))
(define (i a b) (if (neg a) #t (neg b)))

If everything is compiled all together in a module, f and g return
java.lang.Boolean, h and i return primitive boolean.


In the REPL, defining neg and then defining each of those four
functions, they all return java.lang.Object.

I still find the type inferencing to be a bit mysterious, I guess the
actual return type of the neg function isn't always being queried when
the IfExp's type is calculated?


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

Re: #t and #f now default to primitive types

[Per Bothner]

On 04/02/2015 10:07 PM, Jamison Hope wrote:
> On Apr 2, 2015, at 9:27 PM, Per Bothner <per@bothner.com> wrote:
>
>> The literals #t and #f are now treated as having primitive boolean types,
>> rather than java.lang.Boolean type.  That is the return type of:
>>
>>     (define (neg x) (if (>= x 0) #f #t))
>>
>> is boolean rather than java.lang.Boolean.
>>
>> Of course you can specify Boolean explicitly if you want:
>>
>>     (define (neg x) ::java.lang.Boolean (if (>= x 0) #f #t))
>
> Thanks, Per.  I find it curious that with neg defined as above
> (returning primitive boolean), these return what they do:
>
> (define (f a b) (and (neg a) (neg b)))
> (define (g a b) (if (neg a) (neg b) #t))
> (define (h a b) (or (neg a) (neg b)))
> (define (i a b) (if (neg a) #t (neg b)))
>
> If everything is compiled all together in a module, f and g return
> java.lang.Boolean, h and i return primitive boolean.
>
>
> In the REPL, defining neg and then defining each of those four
> functions, they all return java.lang.Object.

I agree that's not very nice.  We can do better.  I need to ponder and
experimentmore.

> I still find the type inferencing to be a bit mysterious, I guess the
> actual return type of the neg function isn't always being queried when
> the IfExp's type is calculated?

I'm not sure yet.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: #t and #f now default to primitive types

[Per Bothner]

On 04/02/2015 10:07 PM, Jamison Hope wrote:
> On Apr 2, 2015, at 9:27 PM, Per Bothner <per@bothner.com> wrote:
>
>> The literals #t and #f are now treated as having primitive boolean types,
>> rather than java.lang.Boolean type.  That is the return type of:
>>
>>     (define (neg x) (if (>= x 0) #f #t))
>>
>> is boolean rather than java.lang.Boolean.
>>
>> Of course you can specify Boolean explicitly if you want:
>>
>>     (define (neg x) ::java.lang.Boolean (if (>= x 0) #f #t))
>
> Thanks, Per.  I find it curious that with neg defined as above
> (returning primitive boolean), these return what they do:
>
> (define (f a b) (and (neg a) (neg b)))
> (define (g a b) (if (neg a) (neg b) #t))
> (define (h a b) (or (neg a) (neg b)))
> (define (i a b) (if (neg a) #t (neg b)))
>
> If everything is compiled all together in a module, f and g return
> java.lang.Boolean, h and i return primitive boolean.

I checked in fixes for this.

> In the REPL, defining neg and then defining each of those four
> functions, they all return java.lang.Object.

Th problem appears to be related to how a function previously compiled
in interactive mode does not get optimized to a method.  We should fix his.
However, that is like to result in even more breakage when trying to
redefine a function.  My tentative plan is to keep track of dependencies
and automatically recompile.  These is some existing support for this.
Better support for clean re-loading/re-definition is fairly high on the
wish-list but it will have to wait until I've cleared some backlog.
(Specifically the "apply" rewrite, which is obviously related.)
I created a Savannah bug to remind me:
https://savannah.gnu.org/bugs/index.php?44718

> I still find the type inferencing to be a bit mysterious, I guess the
> actual return type of the neg function isn't always being queried when
> the IfExp's type is calculated?

It is - normally, but interactive mode doesn't work as well.
Plus there was an obscure bug in how #t/#f was handled, so I
tried a different approach - which uncovered some other problems.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/