On Fri, 2008-03-28 at 01:51 +0100, Pierre THIERRY wrote: > Scribit Jonathan S. Shapiro dies 27/03/2008 hora 15:34: > > We have an open issue concerning initializer expressions. At the > > moment, we permit arbitrary expressions. This can lead to forward > > reference issues and also to non-terminating initializers. > > Is it really an issue to let the user shoot himself in the foot? Are the > problematic cases detectable? Could it be an option for the compiler?
Yes. The main goal of BitC is to have a language whose programs can be analyzed. You can't do that unless the initialization semantics is well defined. > I'd be happy if I could switch to any of: > > - let me do what I want and shut up > - give me a warning when I use any non provably safe forms > - give me a fatal error when I use any non provably safe forms Then the language you want is C++. > Note that I have a bias here: I like Common Lisp partly because the > whole expressive power of the language is available both at compile time > as well as run time. Me too, but you can do all of that in a fully static language as well if you can construct an init section in a consistent way. Supporting an interactive mode is a completely orthogonal issue. And yes, I want it too. > And there are quite nasty corner cases with expressions evaluated at > compile time to be used at run time, and many ways to screw up > unexpectedly. Yes. You have to make sure that the evaluation happens under the same rules as the target, and in the evaluation environment of the target. It gets *really* fun in cross environments. Fortunately, bitc only implements one architecture-dependent type, but the byte order issues are non-trivial. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
