felix.winkelm...@bevuta.com writes:
>> > Interprocedural flow-analysis is hard, we shouldn't underestimate
>> > this. What happens when we declare a type for a toplevel function?
>>
>> If you're thinking about reassigning globals, how about making
>> -fixnum-arithmetic imply -local? If globals
On Mon, May 20, 2019 at 05:09:47PM +0200, felix.winkelm...@bevuta.com wrote:
> > Note that Wasamasa pointed out on IRC that we still need to add -feature
> > to chicken-install, which ties in nicely with cond-expand (see
> > https://bugs.call-cc.org/ticket/1617)
>
> Isn't this already the case?
> Note that Wasamasa pointed out on IRC that we still need to add -feature
> to chicken-install, which ties in nicely with cond-expand (see
> https://bugs.call-cc.org/ticket/1617)
Isn't this already the case? (f701e594dd59b8ab4dc04d340e81440f84ae5d9a)
felix
On Mon, May 20, 2019 at 03:15:20PM +0200, felix.winkelm...@bevuta.com wrote:
> > > Interprocedural flow-analysis is hard, we shouldn't underestimate
> > > this. What happens when we declare a type for a toplevel function?
> >
> > If you're thinking about reassigning globals, how about making
> >
> > Interprocedural flow-analysis is hard, we shouldn't underestimate
> > this. What happens when we declare a type for a toplevel function?
>
> If you're thinking about reassigning globals, how about making
> -fixnum-arithmetic imply -local? If globals cannot be re-defined then
> the types are
felix.winkelm...@bevuta.com writes:
>> > Shouldn't the types.db specialization for scheme#= be applied
>> > here? Or can't it figure out the ffixnum types of the arguments?
>> > Even though it is slightly dangerous, the scrutinizer _could_ assume
>> > arguments to numerical primitives are
On Mon, May 20, 2019 at 01:57:29PM +0200, felix.winkelm...@bevuta.com wrote:
> > Besides, like I said in the other mail, then we'd still be calling
> > allocating functions because (+ fixnum fixnum) => (or fixnum bignum).
> > In fixnum mode, we'd want to use the overflowing unsafe fixnum ops.
>
>
> Besides, like I said in the other mail, then we'd still be calling
> allocating functions because (+ fixnum fixnum) => (or fixnum bignum).
> In fixnum mode, we'd want to use the overflowing unsafe fixnum ops.
And I think that is a situation where assuming a specific type is ok,
or at least not
> > Shouldn't the types.db specialization for scheme#= be applied
> > here? Or can't it figure out the ffixnum types of the arguments?
> > Even though it is slightly dangerous, the scrutinizer _could_ assume
> > arguments to numerical primitives are fixnums in fixnum mode...
>
> That's right, the
