www.digitalmars.com         C & C++   DMDScript  

D - Idea - Compile Time functions

reply J Anderson <anderson badmama.com.au.REMOVE> writes:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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); }

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 "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:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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...

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).

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...

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