www.digitalmars.com         C & C++   DMDScript  

D - Idea - Compile Time functions

reply J Anderson <anderson badmama.com.au.REMOVE> writes:
I've been pondering over this idea for a few weeks.  What about 
functions/methods that are built and ran at compile time.  Admittedly 
this sounds a bit like pre-processing, but it's not.

    * One use for this would be to load resources such as bmp files into
      the executable.  ie

compile Picture loadBMP(char[] filename) {...} //This method will only 
run at compile time
...
Picture something = loadBMP("mypicture.bmp"); //Picture class is build 
and created at compile time, with the picture image inside.

Of course then you need compile time classes, and it may never end.  
Parhaps only libraries could be compile time, or something like that.

    * Another use would be for creating a static class registry.
    * Yet another use would be for more advanced compile time checking
      ie like an advanced static assert.

-Anderson

Should I send it no, yes, no...
Sep 22 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 I've been pondering over this idea for a few weeks.  What about
 functions/methods that are built and ran at compile time.
 Admittedly this sounds a bit like pre-processing, but it's not.


I like the idea too... since it would help make metaprogramming
easier by allowing to do some things using function syntax...

    compile int matrix_size(int a, int b) { return a * b; }

    double [matrix_size(4, 5)] my_array;

What I'm not sure it weither we should allows arbitrary code
in those functions or if we should only allows constant expression
evaluation (this might include math function like sin).

    const double sin30 = sin(deg2rad(30));

I would think that a compile time function would need to have
a return value that is a constant (or maybe a global object).
The function must be evaluable at compile-time and have no
side-effect...

Here we see that we would like to have functions that can be
both compile-time or run-time... Will this cause a debate like
we have seen in C++ on the utility of inline... Would we need
another modifier to say either compile or run-time (we were
having a similar question for static vs run-time assert)?


 Yet another use would be for more advanced compile time
 checking ie like an advanced static assert.


like the following:

    template (T)    // T should be integral type
    compile same_size(T t1, T t2)
    {
        static_assert(t1 == t2);
    }

In that case, we would like the compiler to give information
on where the function was called and the argument that were
passed (same thing for any other compilor error or warning).

Again, one thing that I think would be great with that is
automatic template instanciation.

    template (T)
    compile T fact(T t)
    {
        return t > 1 ? fact(t -1) : 1;
    }

    int f = fact(4);    // f = 4 * 3 * 2 * 1
Sep 22 2003
parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
Philippe Mori wrote:


I've been pondering over this idea for a few weeks.  What about
functions/methods that are built and ran at compile time.
Admittedly this sounds a bit like pre-processing, but it's not.
    


I like the idea too... since it would help make metaprogramming
easier by allowing to do some things using function syntax...

    compile int matrix_size(int a, int b) { return a * b; }

    double [matrix_size(4, 5)] my_array;

What I'm not sure it weither we should allows arbitrary code
in those functions or if we should only allows constant expression
evaluation (this might include math function like sin).

    const double sin30 = sin(deg2rad(30));

I would think that a compile time function would need to have
a return value that is a constant (or maybe a global object).
The function must be evaluable at compile-time and have no
side-effect...

Here we see that we would like to have functions that can be
both compile-time or run-time... Will this cause a debate like
we have seen in C++ on the utility of inline... Would we need
another modifier to say either compile or run-time (we were
having a similar question for static vs run-time assert)?

  


I was thinking about that also. Parhaps the compile part need not be 
tied to the function. Parhaps it should be tied to the call like:

Picture something = compile(loadBMP("mypicture.bmp"));

Now that makes more sense, and could be used with the library only 
policy I suggest.


Yet another use would be for more advanced compile time
checking ie like an advanced static assert.
    


like the following:

    template (T)    // T should be integral type
    compile same_size(T t1, T t2)
    {
        static_assert(t1 == t2);
    }

  


Yeah, although if it was compile time, assert would act like static_assert.


In that case, we would like the compiler to give information
on where the function was called and the argument that were
passed (same thing for any other compilor error or warning).

  


If you had a stack trace, it wouldn't be much of a problem.


Again, one thing that I think would be great with that is
automatic template instanciation.

    template (T)
    compile T fact(T t)
    {
        return t > 1 ? fact(t -1) : 1;
    }

    int f = fact(4);    // f = 4 * 3 * 2 * 1

  


-Anderson
Sep 22 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 I've been pondering over this idea for a few weeks.  What about
 functions/methods that are built and ran at compile time.
 Admittedly this sounds a bit like pre-processing, but it's not.


If the compiler must allocate memory which would probably be the
case   for any classes (except those qualified with auto), something
needs to be done at run-time (allocating the memory for the object)
and I think that otherwise it might be complicate to implement...

Also, if the compiler can always do something at compile time,
why sometime it should be done at run-time. The compiler
should then simply compute the tradeoff (size, performance,..)
and do it the better way...


 I was thinking about that also. Parhaps the compile part need not
 be tied to the function. Parhaps it should be tied to the call like:



 Picture something = compile(loadBMP("mypicture.bmp"));


This can be cool for function like sin, cos and the like... but I
think it will almost never applies otherwise as I think it is not
possible to easily implement it so that arbitrary code can be run
at compile-time...

Maybe the best would be to have no keyword and the compiler
decide itself what it does at compile time and will issues an
error if we try to uses at compile-time a function that can be
used only at run-time... In debug builds, probably we will
want everything to be done at run-time except in the case
where a function is used at a place where a compile-time
call is required (for example an integer template argument).


 Now that makes more sense, and could be used with the library
 only policy I suggest.


I haven't read about that...
Sep 22 2003
parent J Anderson <anderson badmama.com.au.REMOVE> writes:
Philippe Mori wrote:


I've been pondering over this idea for a few weeks.  What about
functions/methods that are built and ran at compile time.
Admittedly this sounds a bit like pre-processing, but it's not.
    


If the compiler must allocate memory which would probably be the
case   for any classes (except those qualified with auto), something
needs to be done at run-time (allocating the memory for the object)
and I think that otherwise it might be complicate to implement...

Also, if the compiler can always do something at compile time,
why sometime it should be done at run-time. The compiler
should then simply compute the tradeoff (size, performance,..)
and do it the better way...

  


Of course it would require memory, but there are a few problems with 
doing it at run-time.
1) Efficiency, if it's done at compile time, the load time is reduced, 
for the user. Also, the memory doesn't need to be dynamic as it would if 
it was loaded at run-time.
2) You can compact everything into one file.
3) A program may be run many times, but it is only ever compiled once.  
This is useful for things such as type information ect...
4) It allows you to customise what is compiled, and how it is compiled.
5) Compile time checking.


I was thinking about that also. Parhaps the compile part need not
be tied to the function. Parhaps it should be tied to the call like:
    


  


Picture something = compile(loadBMP("mypicture.bmp"));
    


This can be cool for function like sin, cos and the like... but I
think it will almost never applies otherwise as I think it is not
possible to easily implement it so that arbitrary code can be run
at compile-time...

Maybe the best would be to have no keyword and the compiler
decide itself what it does at compile time and will issues an
error if we try to uses at compile-time a function that can be
used only at run-time... In debug builds, probably we will
want everything to be done at run-time except in the case
where a function is used at a place where a compile-time
call is required (for example an integer template argument).

  


I think compile time functions would be something that would be applied 
near the end of a programs development cycle, as it could increase 
compile times for debug mode.


Now that makes more sense, and could be used with the library
only policy I suggest.
    


I haven't read about that...

  


I was just saying that only libraries could be used at compile time 
since they are already compiled. It's be no more effort for the compiler 
then just finding the program execution point in the library, and 
passing in the correct parameters.
Sep 22 2003