[bitc-dev] Static initializer expressions

[Jonathan S. Shapiro]

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