On Thu, 2008-07-17 at 09:24 -0700, Eric Rannaud wrote: > Also, one must not forget the various needs for conditional compilation, > sometimes at a local level in the code. It is never a nice thing to do, > but hardware can be quite capricious and it is sometimes necessary to > use macros in that way.
This is a serious issue. At the moment, the only support that BitC has for conditional compilation is to specify an interface that encapsulates the conditionally compiled code, and then use different implementations. Alternatively, one can specify an interface *name* that encapsulates the conditional compilation boundary, and provide distinct implementations of that interface by hacking the interface include path. There is no mechanism, at the moment, for conditionally compiled code. If we decide to adopt the notion of quantification over quasi-terms, we can mandate that quasi-terms be evaluated at compile time. If we now state that (if e-test e-then e-else) is a quasi-term exactly if e-test is a quasi-term, we have conditional compilation at compile time. This won't absolve you of the need for the whole IF expression to type check before the quasi-term resolution is performed, but it *will* guarantee (at least in a whole-program compile) that the inactive cases can be removed at compile time. In fact, we could hypothetically go further and state that if e-test is a quasi-term, then e-then and e-else do not need to have compatible types, and that the result type of IF is determined based on the compile-time value of e-test. My sense is that this is a bad idea, because it means that parts of the program are never fully type-checked. That doesn't seem like a terribly clever plan to me. All of that being said, the Coyotos kernel (so far as I can remember) doesn't have any conditional compilation that can't be resolved by playing with interface paths. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
