From: "Hal E. Fulton" <hal9000@...>
Date: 2003-01-07T00:56:53+09:00
Subject: Re: Compile time constant folding?

----- Original Message -----
From: "Mark Probert" <probertm@nortelnetworks.com>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Monday, January 06, 2003 9:24 AM
Subject: Re: Compile time constant folding?


> At 10:08 AM 1/6/2003 +0900, Dan wrote:
> >At 9:19 AM +0900 1/6/03, Mark Probert wrote:
> >>Dan Sugalski wrote in comp.lang.ruby:
> >>>
> >>>  Is it valid to do compile-time constant folding as an optimization?
> >>
> >>IMO, the POLS wouldn't be breeched if this were to happen.
> >
> >I can see it going either way--the interpreter could do what it's doing
on
> >purpose, or because the optimization just never was done. (Or that it
> >wasn't ever really thought about)
> >
> >It's not like this is expensive in the simple case, but when you do
> >something like:
> >
> >    (1 / sin(2.3)) * log(4)
> >
> >in a loop, well, that can add up pretty quickly.
>
> I say: 15.002 --> optimise.  ;-)
> Given that we know the base, and it is also constant.
>
> This is the thing for me.  Constants are, well, constants.
> If someone redefines "log" to be "ln", then it is no longer
> constant and you should probably have to recompile everything
> anyway.  Either you meant "15.002" (log) or you meant "34.544"
> (ln) when you coded this.
>
> Or is my understanding faulty?  Can you have a constant that
> is context dependant, post-fact?

<sigh/>

I can't respond to your last question, but I'll try to address
the overall issue here.

Redefining things like Fixnum#+ to behave differently may be
bad coding style... but it is possible. As someone said, when
software prevents you from doing stupid things, it often
prevents you from doing very clever things as well.

I'm undecided about whether + and log are logically different...
the difference may be all in my head. After all, they're both
methods.

In any case, I'm even *less* inclined to optimise things like
log and sin. It's hard to explain why, but it just feels wrong
to me. <rhetorical> What about user-defined methods? Should we
assume that a method called with a constant, e.g. foo(5), is a
constant value also? </rhetorical>

On the other hand, maybe it would be acceptable to have an option
like "-mathopt" that would tell the compiler "I hereby certify
that this program does No Funny Business with the standard math
operators and functions, so optimize away, my little friend."
But then we take our first step down the road to Compiler Flag
Hell. The next step, of course, might be "-stropt" or some such.

If we decide to let the compiler optimize "on its own judgment"
(which I think I'm opposed to unless it's Turing-capable, and
that's not coming till version 2.0), then the dynamic nature
of the language causes problems for us. If an operator is
redefined, we probably don't want to optimize (incorrect??),
but it becomes an interesting compile-time exercise to determine
whether a certain piece of code can be executed only before the
redefinition, only after, or potentially both.

While I'm rambling, I might as well say that if the compiler can
detect such optimizing situations, it could in theory report
them to the user in the form of (optional) warnings. That might
be useful.

Just my thoughts.

Hal