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

[Per Bothner <per at bothner dot com>]

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/