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 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. > > I understand - but I'm wary of options implying other options. This makes > it hard to figure out the final set of applicable settings, in the name of > convenience > I have made this mistake often enough. If one wants speed, "-O<n>" is probably > the easiest and simplest way. Otherwise each option should have a single > effect only. Are you talking about deciding "what features should be enabled given this set of features is requested"? Using a simple dependency resolver with declarative dependencies makes that really nice: (add-option x implies: (y z) conflicts: (a b)) I used this kind of system for a toy code obfuscator many years ago when the conditional logic to do it in code got too hairy to follow. I think some of the options were internal and some could be given from command line. > > > felix _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers