Expressions in initializers

[Dave P. Schaumann]

In article <31134 at shamash.cdc.com> ddh at dash.udev.cdc.com (Dan Horsfall) writes:
>OK, heres my $0.02.  How many of you out there really want "constant 
>expressions" evaluated over and over again at run-time??  How many
>times will your code be run, vs. how many times will be it be 
>compiled? 

I think that this is a valid question for anyone who thinks about programming
languages, and how to make them more useful, and not just to those producing
code to be sold.

The root question here is really "how much work should the compiler do to
optimize your program?"  Now, constant evaluation is an obvious thing to
do at compile time.  It has the advantage that you can use constant expressions
wherever you can use a constant.  The disadvantage of this is that to do
this, you have to have an expression interpreter inside the compiler.

Now, for "hardware-defined" operations like + - * / etc, you essentially
get expression evaluation for free when you do expression parsing.  The
trouble starts when you want to do something non-trivial (square-root being
the motivating example).

Now, if your machine has a built-in square-root operation, this is still not
too bad.  But consider the more general case.  We would really want to be able
to use *any* function available in the standard library.  That means that the
full standard library must be available for execution at compile time.  It
should be clear that this is going to make your compiler *a lot* bigger.

But how useful is it to be able to call any standard function at compile
time?  In some cases, it could be very useful.  If you have a large, constant
table with values dependent on functions in the standard library, clearly
this is a big win.  However, in my experience, this is a rather exceptional
occurrance, and the expanded compiler is a big lose to anyone who doesn't
need/use/want this feature.

Also, I should mention that there are some obvious work-arounds (although
none as attractive as compile-time evaluation) to this problem:
	- evaluation at start of run-time (could be slow)
	- using a pre-compiler to evaluate constants (increases the complexity
	  of the source, and introduces precision loss due to 
	  internal/external conversion (if your using float/doubles))

As an aside, does anyone know if Fortran (being the canonical number-crunching
language) allows this sort of thing?

-- 
Dave Schaumann | dave at cs.arizona.edu | Short .sig's rule!