February 16, 2007
On Thu, 15 Feb 2007 10:23:43 -0800, Walter Bright wrote:

> ... is now in DMD 1.006. For example:
On Thu, 15 Feb 2007 10:23:43 -0800, Walter Bright wrote:

> ... is now in DMD 1.006.

I guess its time I came clean and admitted that in spite of this being a huge technological advancement in the language, I can't see why I'd ever be needing it.

I mean, when it comes down to it, it's just a fancy way of getting the compiler to calculate/generate literals that can be done by myself anyway, no? These literals are values that can be determined prior to writing one's code, right?

This is not a troll posting, so can anyone enlighten me on how this ability will reduce the cost of maintaining code? I am very open to being educated.

I'm thinking of the funny side this too, when it comes to putting some DbC validity tests in your code...

   const float x = SomeCompileTimeFunc(1,2,3);
   assert (x == 34.56); // Make sure the function worked.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
16/02/2007 3:24:40 PM
February 16, 2007
"Derek Parnell" <derek@nomail.afraid.org> wrote in message news:15k9gflddwrnp.qzqynewwbuou$.dlg@40tude.net...
> I'm thinking of the funny side this too, when it comes to putting some DbC validity tests in your code...
>
>   const float x = SomeCompileTimeFunc(1,2,3);
>   assert (x == 34.56); // Make sure the function worked.

You mean

static assert(x == 34.56);

;)


February 16, 2007
Derek Parnell wrote:
> On Thu, 15 Feb 2007 10:23:43 -0800, Walter Bright wrote:
> 
>> ... is now in DMD 1.006. For example:
> On Thu, 15 Feb 2007 10:23:43 -0800, Walter Bright wrote:
> 
>> ... is now in DMD 1.006.
> 
> I guess its time I came clean and admitted that in spite of this being a
> huge technological advancement in the language, I can't see why I'd ever be
> needing it.
> 
> I mean, when it comes down to it, it's just a fancy way of getting the
> compiler to calculate/generate literals that can be done by myself anyway,
> no? These literals are values that can be determined prior to writing one's
> code, right?

This is by far the least interesting application of this stuff. I don't even count it when I think of the feature. "Oh, yeah, I could compile square root at compile time. How quaint."

> This is not a troll posting, so can anyone enlighten me on how this ability
> will reduce the cost of maintaining code? I am very open to being educated.

Great. The main uses of the feature will be in creating libraries that work with and _on_ your code (in the most literal sense). I've given the regexp example a few posts back: using the straight regular expression syntax, you direct a library into generating optimal code for each and every of your regular expressions, without ever having to do anything about it.

There's been also much discussion about the applications of code generation, and you can be sure they will be simplified by one order of magnitude by dual functions.


Andrei
February 16, 2007
Walter Bright wrote:
> ... is now in DMD 1.006. For example:
> 
>> -------------------------------------------
>> import std.stdio;
>>
>> real sqrt(real x)
>> {
>>    real root = x / 2;
>>    for (int ntries = 0; ntries < 5; ntries++)
>>    {
>>        if (root * root - x == 0)
>>            break;
>>        root = (root + x / root) / 2;
>>    }
>>    return root;
>> }
>>
>> void main()
>> {
>>    static x = sqrt(10);   // woo-hoo! set to 3.16228 at compile time!
>>    writefln("%s, %s", x, sqrt(10));  // this sqrt(10) runs at run time
>> }
>> ------------------------------------------
> 
> This should obsolete using templates to compute values at compile time.

Man this kicks ass!!!  Its the best implementation we could hope for.

-Joel
February 16, 2007
Walter Bright wrote:
> Michiel wrote:
>> * the syntax for functions to be executed at compile time isn't the
>> nice-and-simple D syntax, but the template-syntax. And in another thread
>> you yourself have mentioned why that's not optimal. I agree.
> 
> I don't think eval!(expression) is an undue burden. It's hard to imagine how any other syntax would look better.
But in many situations, you could view compile-time function execution simply as a high-level optimization, an extension on 'inline'. Why, then, does it make sense to require explicit eval!() annotations, when it clearly doesn't make sense to do this for inline?

Viewing this as a more complex extension to inlining, I think the correct approach is to allow explicit annotations for 'only at runtime' and 'only at compile time' and have the rest decided according to a compiler switch, eg -pre-eval

Cheers,

Reiner
February 16, 2007
Bill Baxter wrote:
> Walter Bright wrote:
>> Walter Bright wrote:
>>> This should obsolete using templates to compute values at compile time.
>>
>> For contrast, compare with the C++ proposal:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1972.pdf
> 
> It's kinda long and boring, but it looks like the key differences are
> 
> 1) The need to tag compile-time functions with a new keyword, "constexpr", though they seem to sell this as an advantage.  "a programmer can state that a function is intended to be used in a constant expression and the compiler can diagnose mistakes." -- page 9.
> 
Would this be useful as an optional tag? Suppose you wanted to make a utils library that was usable in both compile-time and run-time form. You write your code trying to follow the rules supplied in the specs, but how do you make sure you haven't slipped up anywhere? Would an additional keyword help here, or do you just have to do all your unit-tests in static form, eg:

char[] itoa(long value) {...}

unittest
{
    static assert(itoa(12345) == "12345");
}

I suppose there'e not much incentive to add a keyword in this situation, but perhaps it could be useful elsewhere?

Cheers,

Reiner
February 16, 2007
Walter Bright wrote:
> Bill Baxter wrote:
> 
> Right now, the compiler will fail if the compile time execution results in infinite recursion or an infinite loop. I'll have to figure out some way to eventually deal with this.

Maybe you could allow the user to specify stack size and maximum iteration per loop/recursion function to the compiler as flags (with some defaults).   This way the user can up the size if they really need it.  This would make it a platform thing.  That way a D compiler could still be made for less powerful systems.

-Joel
February 16, 2007
On Thu, 15 Feb 2007 20:45:04 -0800, Andrei Alexandrescu (See Website For
Email) wrote:


> There's been also much discussion about the applications of code generation, and you can be sure they will be simplified by one order of magnitude by dual functions.

So this would mean that I could code ...

    mixin(
          Conv("moveto 34,56 "
               "drawto +100,-50 "
               "drawto +0,+100 "
               "pencolor red "
               "drawto -100,-50 "
              );
          );

And expect that the Conv function will, at compile time, create the equivalent D code to implement the 2D drawn item for the target platform, and have the mixin insert it into the program being compiled.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
16/02/2007 4:06:53 PM
February 16, 2007
On Thu, 15 Feb 2007 17:52:38 -0700, Russell Lewis wrote:

> 
> import std.stdio;
> void main() {
>    writefln("%d\n", CalculateTheAnswerToLifeUniverseEverything());
> }
> 
> if it took 7.5 million years to run on a supercomputer, how long is it going to take to run on your compiler?

  int CalculateTheAnswerToLifeUniverseEverything() { return 42; }

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
16/02/2007 4:37:59 PM
February 16, 2007
Derek Parnell wrote:
> On Thu, 15 Feb 2007 20:45:04 -0800, Andrei Alexandrescu (See Website For
> Email) wrote:
> 
> 
>> There's been also much discussion about the applications of code generation, and you can be sure they will be simplified by one order of magnitude by dual functions.
> 
> So this would mean that I could code ...
> 
>     mixin(
>           Conv("moveto 34,56 "
>                "drawto +100,-50 "
>                "drawto +0,+100 "
>                "pencolor red "
>                "drawto -100,-50 "
>               );
>           );
> 
> And expect that the Conv function will, at compile time, create the
> equivalent D code to implement the 2D drawn item for the target platform,
> and have the mixin insert it into the program being compiled. 

I'm thinking of the much more boring and much crappier job of generating proxy and stub code for RPC and IPC.

Andrei