[Issue 1475] allow to use intrinsic math functions (e.g. trigonometry) in CTFEs

[Bill Baxter]

BCS wrote:
> Sean Kelly wrote:
>> d-bugmail at puremagic.com wrote:
>>
>>>
>>> ------- Comment #2 from wbaxter at gmail.com  2007-09-05 16:10 -------
>>> Of course you can already do this by writing your own CTFE functions to
>>> approximate those via Taylor series and the like.  One of the first 
>>> CTFE demos
>>> was a compile-time sqrt function.
>>>
>>> But yeh, the compiler has access to a better way to evaluate those 
>>> functions
>>> than running what amounts to an interpreted language, so it would be 
>>> nice to be
>>> able to access it.
>>
>>
>> It was my impression that CTFE relies on a fancy version of constant 
>> folding, which doesn't make support for any special routines or 
>> plugins a really natural fit.  

Check out dmd/src/dmd/constfold.c and interpret.c.   It's basically a 
little compile time code interpreter.  So yes, it's "fancy constant 
folding" but "fancy" in this case means "it runs a small interpreted 
subset of D". For instance there's a function Cat there which apparently 
does array concatenation.  There's a Div() that does division.  There's 
no reason there couldn't be a function called "Cos" in there that 
computed the cosine of its argument at compile time.  But why stop at Cos?

Wouldn't it be nice if users could add other functions like Cos that 
could be called at compile time?  If they could extend the 
constant-folding interpreter with new built-in functions written in D or 
asm or whatever is convenient.  Mr. thecybershadow needs sin and cos, 
but maybe I need erf(), or maybe I'd like to call BLAS to precompute the 
LU decomposition of some matrix to use as a constant.  Or maybe I'd like 
to have a constant initialized with a string representing the current 
date and time.

So then the question becomes how do you enable constfold.c to call code 
that it doesn't know about it?  That's why I went for DLLs first. 
That's how other interpreted languages are usually extended with 
functionality that can't be expressed in the the language itself, or 
functionality which is available in foreign code.  But maybe BCS is 
right that, since what we're talking about *is* a D compiler to begin 
with, maybe it could access the results of it's own output in a more 
direct way.  I think that would be tough to implement, though, since 
code generation happens miles away from where constfold.c is doing its 
thing.


>> And while it seems like a potentially 
>> interesting feature to add, I wonder whether there might be issues 
>> related to cross compilation.

I don't think anything more than the usual "feature X not supported on 
platform Y".

I think the bigger issue is probably that Walter doesn't want the 
compiler to become a vector for running arbitrary code.  "Hey can you 
compile this D code for me" should never be a way to pz0wn a computer, 
at least according to Walter.

> Intrinsics are just function that get special handling. Something akin 
> to that could be done for CTFE. Put some special case rules in the 
> engine for sin/cos/tan/etc. that call functions that are part of the 
> compiler.

Yeh.  Looking at constfold.c, I think Walter could have probably already 
implemented this for sin/cos/tan in less than the time it took me to 
write this message.  But if sin/cos/tan go in, what about erf, what 
about gettimeofday?  where do you stop?  The classic answer to that is 
"let the user decide" by making it possible to write libraries.

--bb