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

Reply via email to