* Re: #t and #f now default to primitive types
2015-04-03 5:07 ` Jamison Hope
@ 2015-04-03 5:47 ` Per Bothner
2015-04-04 0:32 ` Per Bothner
1 sibling, 0 replies; 4+ messages in thread
From: Per Bothner @ 2015-04-03 5:47 UTC (permalink / raw)
To: kawa
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: #t and #f now default to primitive types
2015-04-03 5:07 ` Jamison Hope
2015-04-03 5:47 ` Per Bothner
@ 2015-04-04 0:32 ` Per Bothner
1 sibling, 0 replies; 4+ messages in thread
From: Per Bothner @ 2015-04-04 0:32 UTC (permalink / raw)
To: kawa
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/
^ permalink raw reply [flat|nested] 4+ messages in thread