[email protected] 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 fixnums in fixnum mode... >> >> That's right, the scrutinizer can't figure out the types. The type of n >> for the first scheme#= call is *. The call enforces the type to number. >> So the second scheme#= is called with (number fixnum). There's no >> specialization for that either. >> >> Wouldn't that kind of assuming lead to hard to debug bugs? > > Yes, that danger is indeed not to be ignored. > >> >> If the scrutinizer could infer types for functions then I think that >> would be fine. You'd get a warning somewhere. > > 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 always correct. If fixnum-arithmetic is wanted for speed then -local is wanted anyway, not to mention global inlining. > > > felix _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
