www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - It seems pure ain't so pure after all

reply "Tommi" <tommitissari hotmail.com> writes:
import std.stdio;

int pow2(int val) pure
{
     if (__ctfe)
         return 6;
     else
         return val * val;
}

void main()
{
            assert(pow2(3) == 9);
     static assert(pow2(3) == 6);

     writeln("9 = 6 ... I knew it! '6' was faking it all along");
     readln();
}
Sep 30 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 01-10-2012 07:40, Tommi wrote:
 import std.stdio;

 int pow2(int val) pure
 {
      if (__ctfe)
          return 6;
      else
          return val * val;
 }

 void main()
 {
             assert(pow2(3) == 9);
      static assert(pow2(3) == 6);

      writeln("9 = 6 ... I knew it! '6' was faking it all along");
      readln();
 }

This is a corner case. __ctfe is there to allow special-cased CTFE code when absolutely necessary. By necessity, this separates a function into two worlds: compile time and run time. As far as purity goes, pow2 *is* pure. It just does something different depending on whether you run it at compile time or run time. I don't see this as a problem in practice. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Sep 30 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/1/12 2:19 AM, Tommi wrote:
 On Monday, 1 October 2012 at 06:13:51 UTC, Brad Roberts wrote:
 So, Tommi, do you have a suggestion or proposal to make or are you
 just trying to point and snicker? There's a
 multitude of ways that bad programmers can write bad code.

I can't provide a solution until we've agreed that there is a problem.

Don't want to sound dismissive, but the short answer is there is no problem. Andrei
Sep 30 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 01/10/2012 08:07, Jonathan M Davis a écrit :
 On Monday, October 01, 2012 07:58:39 Tommi wrote:
 On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen

 wrote:
 As far as purity goes, pow2 *is* pure. ...

According to http://en.wikipedia.org/wiki/Pure_function it's not: "The [pure] function always evaluates the same result value given the same argument value(s)"

Forget what Wikipedia says about pure. If you focus on that, you're going to be complaining about D's pure left and right, because what it's talking about and what D does are related but very different. D takes a very practical approach to functional purity. You should read this: http://stackoverflow.com/questions/8572399 - Jonathan M Davis

Or that : http://klickverbot.at/blog/2012/05/purity-in-d/
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen 
wrote:
 As far as purity goes, pow2 *is* pure. ...

According to http://en.wikipedia.org/wiki/Pure_function it's not: "The [pure] function always evaluates the same result value given the same argument value(s)"
Sep 30 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 07:43:59 Alex R=C3=B8nne Petersen wrote:
 This is a corner case.
=20
 __ctfe is there to allow special-cased CTFE code when absolutely
 necessary. By necessity, this separates a function into two worlds:
 compile time and run time.
=20
 As far as purity goes, pow2 *is* pure. It just does something differe=

 depending on whether you run it at compile time or run time. I don't =

 this as a problem in practice.

It would be kind of like complaining that a pure function returns diffe= rent=20 values on Linux and Windows due to a version statement or static if. It= 's just=20 that in the thing that varies is compile time vs runtime not the target= =20 machine. e.g. int func(int val) pure { version(linux) return val + 2; else version(Windows) return val + 3; } - Jonathan M Davis
Sep 30 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 07:58:39 Tommi wrote:
 On Monday, 1 October 2012 at 05:43:39 UTC, Alex R=C3=B8nne Petersen
=20
 wrote:
 As far as purity goes, pow2 *is* pure. ...

According to http://en.wikipedia.org/wiki/Pure_function it's not: =20 "The [pure] function always evaluates the same result value given the same argument value(s)"

Forget what Wikipedia says about pure. If you focus on that, you're goi= ng to=20 be complaining about D's pure left and right, because what it's talking= about=20 and what D does are related but very different. D takes a very practica= l=20 approach to functional purity. You should read this: http://stackoverflow.com/questions/8572399 - Jonathan M Davis
Sep 30 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
 It would be kind of like complaining that a pure function 
 returns different
 values on Linux and Windows due to a version statement or 
 static if. It's just
 that in the thing that varies is compile time vs runtime not 
 the target
 machine. e.g.

Actually... let's not even worry about the definition of the word 'pure'. Let's just ask ourselves: do we really want to live in a world where people can write code like that: void main() { auto x = pow2(3); enum y = pow2(3); assert(x == y + 3); writeln("Take that mr. \"math\" professor!"); readln(); }
Sep 30 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 9/30/2012 11:09 PM, Tommi wrote:
 On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
 It would be kind of like complaining that a pure function returns different
 values on Linux and Windows due to a version statement or static if. It's just
 that in the thing that varies is compile time vs runtime not the target
 machine. e.g.

Actually... let's not even worry about the definition of the word 'pure'. Let's just ask ourselves: do we really want to live in a world where people can write code like that: void main() { auto x = pow2(3); enum y = pow2(3); assert(x == y + 3); writeln("Take that mr. \"math\" professor!"); readln(); }

So, Tommi, do you have a suggestion or proposal to make or are you just trying to point and snicker? There's a multitude of ways that bad programmers can write bad code.
Sep 30 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 08:09:38 Tommi wrote:
 On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
 It would be kind of like complaining that a pure function
 returns different
 values on Linux and Windows due to a version statement or
 static if. It's just
 that in the thing that varies is compile time vs runtime not
 the target
 machine. e.g.

Actually... let's not even worry about the definition of the word 'pure'. Let's just ask ourselves: do we really want to live in a world where people can write code like that: void main() { auto x = pow2(3); enum y = pow2(3); assert(x == y + 3); writeln("Take that mr. \"math\" professor!"); readln(); }

Then don't write a function which claims to square a value and does something else. That's just bad naming. No language is going to prevent programmers from being idiots. A function which uses __ctfe should probably do essentially the same thing at both runtime and compile time, but it _has_ __ctfe, because the runtime implementation won't work at compile time, and it's up to the programmer to make sure that the function does what it's supposed to at both compile time and runtime. The compiler can't possibly enforce that. - Jonathan M Davis
Sep 30 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 06:13:51 UTC, Brad Roberts wrote:
 So, Tommi, do you have a suggestion or proposal to make or are 
 you just trying to point and snicker?  There's a
 multitude of ways that bad programmers can write bad code.

I can't provide a solution until we've agreed that there is a problem.
Sep 30 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis wrote:
 A function which uses __ctfe should probably do essentially the 
 same thing at
 both runtime and compile time, but it _has_ __ctfe, because the 
 runtime
 implementation won't work at compile time, and it's up to the 
 programmer to
 make sure that the function does what it's supposed to at both 
 compile time
 and runtime. The compiler can't possibly enforce that.

Thus we're in a situation where pure means pure only by convention, not because it's enforced by the compiler. It's like const in c++ then, it's const only by convention, only because people promise that they're not going to mutate it. I don't like rules that are enforced only by everybody relying on good manners.
Sep 30 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 08:25:39 Tommi wrote:
 On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis wrote:
 A function which uses __ctfe should probably do essentially the
 same thing at
 both runtime and compile time, but it _has_ __ctfe, because the
 runtime
 implementation won't work at compile time, and it's up to the
 programmer to
 make sure that the function does what it's supposed to at both
 compile time
 and runtime. The compiler can't possibly enforce that.

Thus we're in a situation where pure means pure only by convention, not because it's enforced by the compiler. It's like const in c++ then, it's const only by convention, only because people promise that they're not going to mutate it. I don't like rules that are enforced only by everybody relying on good manners.

No. We're not in that situation at all. The function will do the same thing with every call at compile time, and it will do the same thing with every call at runtime. It's like you're complaining about the fact that a function on a big endian machine doesn't do exactly the same thing as when it's compiled for a little endian machine. It's being compiled for a different environment, so its behavior can change. __ctfe really isn't all that different from static if or version blocks which effectively result in different functions depending on how or where the code is compiled. What isn't enforced is that the function does the same thing at compile time as at runtime, and you can't enforce that any more than you can enforce that it does the same thing on one machine as another when they have different architectures or OSes or whatot. By using __ctfe, you are providing an alternate implementation for compile time just like you could provide alternate implementations for different OSes or architectures. - Jonathan M Davis
Sep 30 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, September 30, 2012 23:38:43 Jonathan M Davis wrote:
 On Monday, October 01, 2012 08:25:39 Tommi wrote:
 Thus we're in a situation where pure means pure only by
 convention, not because it's enforced by the compiler. It's like
 const in c++ then, it's const only by convention, only because
 people promise that they're not going to mutate it. I don't like
 rules that are enforced only by everybody relying on good manners.

No. We're not in that situation at all. The function will do the same thing with every call at compile time, and it will do the same thing with every call at runtime. It's like you're complaining about the fact that a function on a big endian machine doesn't do exactly the same thing as when it's compiled for a little endian machine. It's being compiled for a different environment, so its behavior can change. __ctfe really isn't all that different from static if or version blocks which effectively result in different functions depending on how or where the code is compiled. What isn't enforced is that the function does the same thing at compile time as at runtime, and you can't enforce that any more than you can enforce that it does the same thing on one machine as another when they have different architectures or OSes or whatot. By using __ctfe, you are providing an alternate implementation for compile time just like you could provide alternate implementations for different OSes or architectures.

While __ctfe is not used in a static if, that's effectively the behavior that it has. You're basically complaining about how these two functions don't return the same value: static if(__ctfe) { int pow2(int val) pure { return 6; } } else { int pow2(int val) pure { return val * val; } } They're effectively completely different functions that share the same name (and presumably the same intent), but they're implementations are different, and it's obviously up to the programmer to make sure that they do what they're supposed to do. It has _nothing_ to do with pure. - Jonathan M Davis
Sep 30 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/01/2012 08:02 PM, foobar wrote:
 On Monday, 1 October 2012 at 17:46:00 UTC, Tommi wrote:
 On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote:
 And you _can't_ determine ahead of time which functions can be safely
 executed at compile time either, because that's an
 instance of the halting problem.

I don't understand (I did read what "halting problem" means just now, but I still don't understand). If there was no __ctfe variable, and thus a guarantee that all functions do the same thing at compile-time and run-time, couldn't the compiler just try aggressively to execute all function calls at compile-time? Obviously it wouldn't bother trying CTFE for function calls that had arguments which weren't evaluable at compile-time. Nor would it bother with functions that it knows have memory allocations or other limitations of CTFE. If not a compiler flag, then it could be a function attribute. Just like c++ function attribute constexpr, which guarantees that the function executes at compile time given you provide it with compile-time evaluable arguments (and there are limitations to what the function can do). Why wouldn't this attribute be possible with D?

__ctfe is a horrible yet very useful hack to address the underlying issue - the execution model for CTFE, which I personally do not agree with. Adding a compiler flag for the existing model, makes no sense whatsoever. Functions are essentially a run-time abstraction and the compiler generally speaking has no business trying to execute them at compile-time. The compiler is after all *not* an interpreter.

A D compiler is also a D interpreter. I wouldn't even bother with D if this wasn't the case.
 Besides, what would be the use case for such a flag anyway? If you
 already know that all parameters are known at compile-time, you can
 already "tell" the compiler to execute the function by assigning to a
 static/enum variable.

 IMO, this mixing of code for various stages of execution is bad design
 but this cannot be changed in a backwards compatible way.

Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
I'll have to consider all functions potentially schizophrenic 
then. They might do one thing at compile-time and another at 
run-time.

I was going to make a feature request to add a compiler flag for 
making more functions execute at compile-time than those which 
the compiler *has* to. But this __ctfe thing renders that 
impossible.
Oct 01 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 1 October 2012 at 06:25:19 UTC, Tommi wrote:
 On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis 
 wrote:
 A function which uses __ctfe should probably do essentially 
 the same thing at
 both runtime and compile time, but it _has_ __ctfe, because 
 the runtime
 implementation won't work at compile time, and it's up to the 
 programmer to
 make sure that the function does what it's supposed to at both 
 compile time
 and runtime. The compiler can't possibly enforce that.

Thus we're in a situation where pure means pure only by convention, not because it's enforced by the compiler. It's like const in c++ then, it's const only by convention, only because people promise that they're not going to mutate it. I don't like rules that are enforced only by everybody relying on good manners.

The only real problem here is that you wrote a function called pow2 that effectively returns 6 unconditionally. I doubt your math professor would be particularly impressed. If you had used __ctfe properly, it would return the same value both at compile-time and runtime. At present, __ctfe is a necessary evil as CTFE can be severely crippled without it.
Oct 01 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 09:46:43 Tommi wrote:
 I'll have to consider all functions potentially schizophrenic
 then. They might do one thing at compile-time and another at
 run-time.

That's only the case if they're buggy, so that's pretty much the same as considering all functions potentially buggy.
 I was going to make a feature request to add a compiler flag for
 making more functions execute at compile-time than those which
 the compiler *has* to. But this __ctfe thing renders that
 impossible.

I have no idea how you could possibly use a compiler flag for that, whether __ctfe or not. It really doesn't make sense to try and make functions in general run at compile time. Most of the time, functions need to be run at runtime, otherwise you wouldn't even need to generate an executable, just a result. And you _can't_ determine ahead of time which functions can be safely executed at compile time either, because that's an instance of the halting problem. So, it really doesn't make sense to have the compiler trying to evaluate functions at compile time when it hasn't been explicitly told to. And it works just fine to assign the result of a function call to enum if you want a specific function call to be executed at compile time, so I really don't think that this is an issue anyway. - Jonathan M Davis
Oct 01 2012
parent Walter Bright <newshound1 digitalmars.com> writes:
On 10/1/2012 1:10 PM, Tommi wrote:
 I meant that all functions would still be
 implicitly CTFEable by default, but an attribute like force_ctfe would
 make it so that the function is guaranteed to execute at compile-time
 when its arguments are compile-time constants.

Since all you need to do to guarantee compile time evaluation is use it in a context that requires CTFE, which are exactly the cases where you'd care that it was CTFE'd, I just don't see much utility here. Note that it is also impossible in the general case for the compiler to guarantee that a specific function is CTFE'able for all arguments that are also CTFE'able.
Oct 01 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 01 Oct 2012 01:40:37 -0400, Tommi <tommitissari hotmail.com> wrote:

 import std.stdio;

 int pow2(int val) pure
 {
      if (__ctfe)
          return 6;
      else
          return val * val;
 }

 void main()
 {
             assert(pow2(3) == 9);
      static assert(pow2(3) == 6);

      writeln("9 = 6 ... I knew it! '6' was faking it all along");
      readln();
 }

You have a bug in your code, here let me fix that for you:
 int pow2(int val) pure
 {
     return val * val;
 }

OK, on to the next thread... -Steve
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote:
 And you _can't_ determine ahead of time which functions can be 
 safely executed at compile time either, because that's an
 instance of the halting problem.

I don't understand (I did read what "halting problem" means just now, but I still don't understand). If there was no __ctfe variable, and thus a guarantee that all functions do the same thing at compile-time and run-time, couldn't the compiler just try aggressively to execute all function calls at compile-time? Obviously it wouldn't bother trying CTFE for function calls that had arguments which weren't evaluable at compile-time. Nor would it bother with functions that it knows have memory allocations or other limitations of CTFE. If not a compiler flag, then it could be a function attribute. Just like c++ function attribute constexpr, which guarantees that the function executes at compile time given you provide it with compile-time evaluable arguments (and there are limitations to what the function can do). Why wouldn't this attribute be possible with D?
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 08:00:47 UTC, Jakob Ovrum wrote:
 The only real problem here is that you wrote a function called 
 pow2 that effectively returns 6 unconditionally. I doubt your 
 math professor would be particularly impressed. If you had used 
 __ctfe properly, it would return the same value both at 
 compile-time and runtime. At present, __ctfe is a necessary 
 evil as CTFE can be severely crippled without it.

I solemnly swear not to use __ctfe improperly. But my problem with it is, that there *exists* the possibility of improper use of __ctfe. Plus, I just realized, I've never actually met any math professor. I never went to a university (nor study programming for that matter).
Oct 01 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 1 October 2012 at 17:46:00 UTC, Tommi wrote:
 On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis 
 wrote:
 And you _can't_ determine ahead of time which functions can be 
 safely executed at compile time either, because that's an
 instance of the halting problem.

I don't understand (I did read what "halting problem" means just now, but I still don't understand). If there was no __ctfe variable, and thus a guarantee that all functions do the same thing at compile-time and run-time, couldn't the compiler just try aggressively to execute all function calls at compile-time? Obviously it wouldn't bother trying CTFE for function calls that had arguments which weren't evaluable at compile-time. Nor would it bother with functions that it knows have memory allocations or other limitations of CTFE. If not a compiler flag, then it could be a function attribute. Just like c++ function attribute constexpr, which guarantees that the function executes at compile time given you provide it with compile-time evaluable arguments (and there are limitations to what the function can do). Why wouldn't this attribute be possible with D?

__ctfe is a horrible yet very useful hack to address the underlying issue - the execution model for CTFE, which I personally do not agree with. Adding a compiler flag for the existing model, makes no sense whatsoever. Functions are essentially a run-time abstraction and the compiler generally speaking has no business trying to execute them at compile-time. The compiler is after all *not* an interpreter. Besides, what would be the use case for such a flag anyway? If you already know that all parameters are known at compile-time, you can already "tell" the compiler to execute the function by assigning to a static/enum variable. IMO, this mixing of code for various stages of execution is bad design but this cannot be changed in a backwards compatible way.
Oct 01 2012
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Monday, 1 October 2012 at 06:09:18 UTC, Tommi wrote:

 Actually... let's not even worry about the definition of the 
 word 'pure'. Let's just ask ourselves: do we really want to 
 live in a world where people can write code like that:

Yes, yes we do, because if we didn't there wouldn't be a _ctfe to make this possible.
Oct 01 2012
prev sibling next sibling parent "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Monday, 1 October 2012 at 17:53:35 UTC, Tommi wrote:
 On Monday, 1 October 2012 at 08:00:47 UTC, Jakob Ovrum wrote:
 The only real problem here is that you wrote a function called 
 pow2 that effectively returns 6 unconditionally. I doubt your 
 math professor would be particularly impressed. If you had 
 used __ctfe properly, it would return the same value both at 
 compile-time and runtime. At present, __ctfe is a necessary 
 evil as CTFE can be severely crippled without it.

I solemnly swear not to use __ctfe improperly. But my problem with it is, that there *exists* the possibility of improper use of __ctfe.

Can you name a programming language that supports CTFE, but doesn't allow the possibility of misuse? Actually, can you name any language with a safety or purity feature that cannot be thwarted by a motivated programmer? To echo Jonathan's sentiment, no programming language can stop a programmer who is determined to write stupid code from doing so. For the sake of discussion, here's an example of a pure function in Haskell (arguably the "purest" language in wide use today) that happily returns a random integer every time it is called. import System.IO.Unsafe import System.Random pureFunction :: () -> Int pureFunction x = unsafePerformIO impureInside where impureInside = getStdRandom (randomR (1,6)) main = do print (pureFunction ()) print (pureFunction ()) print (pureFunction ()) This prints three random integers between 1 and 6 when executed. -- Graham
Oct 01 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 19:53:53 Tommi wrote:
 I solemnly swear not to use __ctfe improperly. But my problem
 with it is, that there *exists* the possibility of improper use
 of __ctfe.

I could just as easily name a function pow2 and make it return the square root. I could overload operator + to do operator -. I could make it so that a function does one thing on Linux and does something completely different and unreleated on Windows. There are _tons_ of places in programming where the programmer has to not be an idiot or their fellow programmers are going to end up with tons of pain. __ctfe is no different from static if or version or any feature which makes it so that the block of code is different on different machines, and it's generally a whale of a lot less error-prone than stuff like endianness issues. It's even trivial to use the same unit tests to test that your function does the same thing in CTFE as at runtime, which you can test on the same machine, unlike with architecture and OS differences. I really think that you're blowing this way out of proportion. Certainly, you think that there's a problem here when the rest of us don't. - Jonathan M Davis
Oct 01 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 19:46:16 Tommi wrote:
 On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote:
 And you _can't_ determine ahead of time which functions can be
 safely executed at compile time either, because that's an
 instance of the halting problem.

I don't understand (I did read what "halting problem" means just now, but I still don't understand). If there was no __ctfe variable, and thus a guarantee that all functions do the same thing at compile-time and run-time,

__ctfe exists purely so that you can provide an alternate implementation which works at compile time when the normal implementation doesn't (since CTFE _is_ more restrictive in what it allows than running a function at runtime is).
 couldn't the compiler just
 try aggressively to execute all function calls at compile-time?

So, the compiler is supposed to run every function at compile time and then back up if it a function doesn't work? It can't even always know for sure when a function doesn't work (e.g. infinite loop). This would absolutely _tank_ compilation times. Most functions _can't_ be run at compile time simply because of how they're called, and the compiler can't necessarily know that unless it does full flow analysis if not outright _runs_ every function, which would be _incredibly_ expensive.
 If not a compiler flag, then it could be a function attribute.
 Just like c++ function attribute constexpr, which guarantees that
 the function executes at compile time given you provide it with
 compile-time evaluable arguments (and there are limitations to
 what the function can do). Why wouldn't this attribute be
 possible with D?

CTFE was specifically designed with the idea that you would not need to mark functions as CTFEable. You can call _any_ function at compile time. Some will fail, because they're doing things that CTFE won't allow, but that's quickly caught, because it happens at compile time. It completely avoids needing to mark functions as CTFEable all over the place (which would generally mean that functions wouldn't be CTFEable, because people would frequently not mark them as CTFEable). constexpr is in direct conflict with that design goal. And if you want a function to be executed at compile time, you assign its result to an enum or static variable. Done. It's easy and straightforward. I really don't understand why this is an issue at all. - Jonathan M Davis
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 18:36:23 UTC, Jonathan M Davis wrote:
 CTFE was specifically designed with the idea that you would not 
 need to mark functions as CTFEable. You can call _any_ functio
 at compile time. Some will fail, because they're doing things 
 that CTFE won't allow, but that's quickly caught, because it 
 happens at compile time. It completely avoids needing to mark
 functions as CTFEable all over the place (which would generally
 mean that functions wouldn't be CTFEable, because people would
 frequently not mark them as CTFEable). constexpr is in direct
 conflict with that design goal.

That's not what I suggested. I meant that all functions would still be implicitly CTFEable by default, but an attribute like force_ctfe would make it so that the function is guaranteed to execute at compile-time when its arguments are compile-time constants.
 And if you want a function to be executed at compile time, you 
 assign its result to an enum or static variable. Done. It's easy
 and straightforward. I really don't understand why this is an
 issue at all.

The issue to me is complicating the syntax of your code. The problem is *having* to assign the result first to an enum, when I shouldn't have to. I would like to be able to just say fun("times") and be confident that that's going to be evaluated at compile-time. I feel like I've done my part of the deal here, I provided the compile-time argument, and now I'd expect the compiler to do his part and evaluate the function at compile-time (if it has that force_ctfe attribute).
Oct 01 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 01 Oct 2012 16:10:48 -0400, Tommi <tommitissari hotmail.com> wrote:

 On Monday, 1 October 2012 at 18:36:23 UTC, Jonathan M Davis wrote:
 CTFE was specifically designed with the idea that you would not need to  
 mark functions as CTFEable. You can call _any_ functio
 at compile time. Some will fail, because they're doing things that CTFE  
 won't allow, but that's quickly caught, because it happens at compile  
 time. It completely avoids needing to mark
 functions as CTFEable all over the place (which would generally
 mean that functions wouldn't be CTFEable, because people would
 frequently not mark them as CTFEable). constexpr is in direct
 conflict with that design goal.

That's not what I suggested. I meant that all functions would still be implicitly CTFEable by default, but an attribute like force_ctfe would make it so that the function is guaranteed to execute at compile-time when its arguments are compile-time constants.
 And if you want a function to be executed at compile time, you assign  
 its result to an enum or static variable. Done. It's easy
 and straightforward. I really don't understand why this is an
 issue at all.

The issue to me is complicating the syntax of your code. The problem is *having* to assign the result first to an enum, when I shouldn't have to. I would like to be able to just say fun("times") and be confident that that's going to be evaluated at compile-time. I feel like I've done my part of the deal here, I provided the compile-time argument, and now I'd expect the compiler to do his part and evaluate the function at compile-time (if it has that force_ctfe attribute).

We already have that, use templates: private auto _funimpl(string s) { /* what was previously in fun(string) */ } template fun(string s) { enum fun = _funimpl(s); } // usage: fun!("times"); // always executes _funimpl at compile time -Steve
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 20:16:09 UTC, Steven Schveighoffer 
wrote:
 We already have that, use templates:

 private auto _funimpl(string s) {
 /* what was previously in fun(string) */
 }

 template fun(string s)
 {
    enum fun = _funimpl(s);
 }

 // usage:

 fun!("times"); // always executes _funimpl at compile time

Yes, I know. And this helps even more: template ct(alias expr) { enum ct = expr; } auto fun(string s) { ... } // usage: ct!(fun("times")) But that's still a nuisance.
Oct 01 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
 private auto _funimpl(string s) {
 /* what was previously in fun(string) */
 }

 template fun(string s)
 {
    enum fun = _funimpl(s);
 }

 // usage:

 fun!("times"); // always executes _funimpl at compile time

 -Steve

You could even use this template: template ct(alias f) { template ct(params...) { enum ct = f(params); } } to define templates like this: alias ct!((string s) { // function body... }) fun; or with this syntax: alias ct!(a => a * a) pow2;
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
It's a lot less work to add one attribute to your function once, 
than to write something extra every time you call that function.
Oct 01 2012
prev sibling next sibling parent "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Monday, 1 October 2012 at 20:30:26 UTC, Tommi wrote:
 It's a lot less work to add one attribute to your function 
 once, than to write something extra every time you call that 
 function.

string exclaim(string v)() { return v ~ "!"; } void main() { writeln(exclaim!("howdy")); } Graham
Oct 01 2012
prev sibling next sibling parent reply "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 20:33:29 UTC, Graham Fawcett wrote:
 string exclaim(string v)() {
   return v ~ "!";
 }

 void main() {
   writeln(exclaim!("howdy"));
 }

It doesn't scale well to have to write both compile-time and run-time versions of your functions.
Oct 01 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/1/12 5:55 PM, Tommi wrote:
 On Monday, 1 October 2012 at 21:35:16 UTC, Jonathan M Davis wrote:
 The question is whether it's worth adding such an attribute to
 the language, and clearly, most of us think that explicitly
 using enum suffices whereas Tommi wants such a function
 attribute.

You'd get simpler syntax at the cost of just one lousy new keyword. It's a once in a life time deal! Any takers?

I understand the motivation. We will not consider such a feature for the time being. Andrei
Oct 01 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 01 Oct 2012 16:23:17 -0400, Tommi <tommitissari hotmail.com> wrote:

 On Monday, 1 October 2012 at 20:16:09 UTC, Steven Schveighoffer wrote:
 We already have that, use templates:

 private auto _funimpl(string s) {
 /* what was previously in fun(string) */
 }

 template fun(string s)
 {
    enum fun = _funimpl(s);
 }

 // usage:

 fun!("times"); // always executes _funimpl at compile time

Yes, I know. And this helps even more: template ct(alias expr) { enum ct = expr; } auto fun(string s) { ... } // usage: ct!(fun("times")) But that's still a nuisance.

Hm... I was focusing on changing fun("times") into fun!("times") in order to make it always execute at compile time. I think that is not so bad. The idea is that _funimpl is implementation details for fun, and doesn't ever expect to be called at runtime. In fact, you could do if(!_ctfe) throw Error(); -Steve
Oct 01 2012
prev sibling next sibling parent "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Monday, 1 October 2012 at 20:41:53 UTC, Tommi wrote:
 On Monday, 1 October 2012 at 20:33:29 UTC, Graham Fawcett wrote:
 string exclaim(string v)() {
  return v ~ "!";
 }

 void main() {
  writeln(exclaim!("howdy"));
 }

It doesn't scale well to have to write both compile-time and run-time versions of your functions.

And how is your proposed force_ctfe attribute going to solve this issue? If you're forcing CTFE, by definition you don't have runtime support. As you clearly know, D already supports functions that can run at compile-time and run-time: that's the whole point of of CTFE. Graham
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 21:15:40 UTC, Graham Fawcett wrote:
 And how is your proposed  force_ctfe attribute going to solve 
 this issue? If you're forcing CTFE, by definition you don't 
 have runtime support.

Maybe the name force_ctfe is misleading. But, like I said: "the attribute asdf would make it so that the function is guaranteed to execute at compile-time when its arguments are compile-time constants". Never do I say that the attribute would prevent run-time evaluation. The function would behave just like constexpr functions do in c++ (although, in c++ what those functions can actually do is much more limited).
Oct 01 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 23:15:55 Graham Fawcett wrote:
 On Monday, 1 October 2012 at 20:41:53 UTC, Tommi wrote:
 On Monday, 1 October 2012 at 20:33:29 UTC, Graham Fawcett wrote:
 string exclaim(string v)() {
 
 return v ~ "!";
 
 }
 
 void main() {
 
 writeln(exclaim!("howdy"));
 
 }

It doesn't scale well to have to write both compile-time and run-time versions of your functions.

And how is your proposed force_ctfe attribute going to solve this issue? If you're forcing CTFE, by definition you don't have runtime support. As you clearly know, D already supports functions that can run at compile-time and run-time: that's the whole point of of CTFE.

If I understand correctly, what he wants is for CTFE to be forced only in cases where all of the arguments are known at compile time (e.g. when you pass a string literal), so it wouldn't prevent anything from running at runtime. This would be a complete disaster if it were done in the general case. For instance, writeln("hello") can't be executed at compile time, and since the only way for the compiler to know that in most cases is to run the function, compile times would tank and probably cause other entertaining issues. So, a compiler flag like was previously suggested in this thread would be a _very_ bad idea. On the other hand, if a function attribute were introduced where the programmer indicated that they wanted that function to execute at compile time as long as all of the arguments were known at compile time, that would work just fine (as long as it really _could_ be executed at compile time - but we already have that issue when assigning the results of functions to enums). The question is whether it's worth adding such an attribute to the language, and clearly, most of us think that explicitly using enum suffices whereas Tommi wants such a function attribute. - Jonathan M Davis
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 21:29:33 UTC, Tommi wrote:
 Maybe the name  force_ctfe is misleading. But, like I said: 
 "the attribute  asdf would make it so that the function is 
 guaranteed to execute at compile-time when its arguments are 
 compile-time constants".

Oh, wait. Now I understand why that sentence is misleading. It should be: The function attribute asdf would guarantee compile-time evaluation of all such calls to that function, where all arguments (that you pass into the function), of which the function's output depends on, are compile-time evaluable.
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 21:35:16 UTC, Jonathan M Davis wrote:
 The question is whether it's worth adding such an attribute to
 the language, and clearly, most of us think that explicitly
 using enum suffices whereas Tommi wants such a function
 attribute.

You'd get simpler syntax at the cost of just one lousy new keyword. It's a once in a life time deal! Any takers?
Oct 01 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 23:55:11 Tommi wrote:
 On Monday, 1 October 2012 at 21:35:16 UTC, Jonathan M Davis wrote:
 The question is whether it's worth adding such an attribute to
 the language, and clearly, most of us think that explicitly
 using enum suffices whereas Tommi wants such a function
 attribute.

You'd get simpler syntax at the cost of just one lousy new keyword. It's a once in a life time deal! Any takers?

Keywords are considered to be incredibly expensive. Being able to use a name starting with rather than a keyword does reduce the cost, but you're still going to have to drive a very hard bargain to talk Walter into adding anything like that to the language at this point. Adding much of _anything_ to the language is generally considered expensive. - Jonathan M Davis
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 22:23:51 UTC, Jonathan M Davis wrote:
 Keywords are considered to be incredibly expensive. Being able 
 to use a name
 starting with   rather than a keyword does reduce the cost, but 
 you're still
 going to have to drive a very hard bargain to talk Walter into 
 adding anything
 like that to the language at this point. Adding much of 
 _anything_ to the
 language is generally considered expensive.

I'm not sure if you meant the same, but I meant the word "cost" of a feature as "the amount the feature complicates the language". Also, I'm only asking people to "buy" this feature in the sense of: "what would you say about this feature if the language was still back on the drawing board and nothing had been written down yet".
Oct 01 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, October 02, 2012 01:19:51 Tommi wrote:
 I'm not sure if you meant the same, but I meant the word "cost"
 of a feature as "the amount the feature complicates the
 language". Also, I'm only asking people to "buy" this feature in
 the sense of: "what would you say about this feature if the
 language was still back on the drawing board and nothing had been
 written down yet".

No offense, but a feature proposal is pretty pointless if it's a "this would have been nice had we had thought of it when we could have easily added it." A feature proposal is only relevant if it's really an attempt to change the language now. If we were really back at the drawing board, there are plenty of other things which would change, some of which could completely change how some things work and possibly invalidate a feature which might seem reasonable now but wouldn't work with the other changes (which probably isn't the case here, but still, discussing what could have been doesn't really buy us anything IMHO). - Jonathan M Davis
Oct 01 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
--14dae93408453f1a1504cb07d18a
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 1, 2012 at 4:19 PM, Tommi <tommitissari hotmail.com> wrote:

 On Monday, 1 October 2012 at 22:23:51 UTC, Jonathan M Davis wrote:

 Keywords are considered to be incredibly expensive. Being able to use a
 name
 starting with   rather than a keyword does reduce the cost, but you're
 still
 going to have to drive a very hard bargain to talk Walter into adding
 anything
 like that to the language at this point. Adding much of _anything_ to the
 language is generally considered expensive.

I'm not sure if you meant the same, but I meant the word "cost" of a feature as "the amount the feature complicates the language". Also, I'm only asking people to "buy" this feature in the sense of: "what would you say about this feature if the language was still back on the drawing board and nothing had been written down yet".

That is a close to useless exercise (or domain problem). Problems to solve are only interested in a specific domain. In other words the problem as you have defined it will have a different solution in D, C++, Java, vaporware language, etc. To some degree it reminds me of the slew of TCP replacement protocols that academia has designed and implemented that will probably never see the day of light. Don't get me wrong it is educational to read them and implementable in private networks but it is highly probably that the Internet will never see them. Thanks, -Jose --14dae93408453f1a1504cb07d18a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 1, 2012 at 4:19 PM, Tommi <span dir=3D"ltr">&lt;<a href=3D"mail= to:tommitissari hotmail.com" target=3D"_blank">tommitissari hotmail.com</a>= &gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> On Monday, 1 October 2012 at 22:23:51 UTC, Jonathan M Davis wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Keywords are considered to be incredibly expensive. Being able to use a nam= e<br> starting with rather than a keyword does reduce the cost, but you&#39;re = still<br> going to have to drive a very hard bargain to talk Walter into adding anyth= ing<br> like that to the language at this point. Adding much of _anything_ to the<b= r> language is generally considered expensive.<br> </blockquote> <br> I&#39;m not sure if you meant the same, but I meant the word &quot;cost&quo= t; of a feature as &quot;the amount the feature complicates the language&qu= ot;. Also, I&#39;m only asking people to &quot;buy&quot; this feature in th= e sense of: &quot;what would you say about this feature if the language was= still back on the drawing board and nothing had been written down yet&quot= ;.<br> </blockquote></div><br><div>That is a close to useless exercise (or domain = problem). Problems to solve are only interested in a specific domain. In ot= her words the problem as you have defined it will have a different solution= in D, C++, Java, vaporware language, etc.</div> <div><br></div><div>To some degree it reminds me of the slew of TCP replace= ment protocols that academia has designed and implemented that will probabl= y never see the day of light. Don&#39;t get me wrong it is educational to r= ead them and implementable in private networks but it is highly probably th= at the Internet will never see them.</div> <div><br></div><div>Thanks,</div><div>-Jose</div> --14dae93408453f1a1504cb07d18a--
Oct 01 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Adding much of _anything_ to the
 language is generally considered expensive.

Sometimes you add from a language removing something, like allowing handy code like this, removing such limitations and making the language more regular/uniform: class Foo { int x, y; } struct Bar { int x, y; } void main() { auto f1 = new Foo(1, 2); auto f2 = new Foo(1); auto b1 = new Bar(10, 20); auto b2 = new Bar(10); } Bye, bearophile
Oct 01 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Monday, 1 October 2012 at 23:31:21 UTC, Jonathan M Davis wrote:
 No offense, but a feature proposal is pretty pointless if it's 
 a "this would
 have been nice had we had thought of it when we could have 
 easily added it." A
 feature proposal is only relevant if it's really an attempt to 
 change the
 language now.

 If we were really back at the drawing board, there are plenty 
 of other things
 which would change, some of which could completely change how 
 some things work
 and possibly invalidate a feature which might seem reasonable 
 now but wouldn't
 work with the other changes (which probably isn't the case 
 here, but still,
 discussing what could have been doesn't really buy us anything 
 IMHO).

 - Jonathan M Davis

I don't think you should stop trying to write the best language specification you can just because you're past the point of it being implementable by this language. Call the specification D++ and maybe some day someone will pick it up and try to implement it.
Oct 01 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, October 02, 2012 02:19:21 Tommi wrote:
 I don't think you should stop trying to write the best language
 specification you can just because you're past the point of it
 being implementable by this language.

Discussing changes to D2 is of relevance, because that affects what we're doing now. Discussing features for a possible D3 is of some relevance, because it could eventually affect the language (but is also kind of pointless in that it won't matter for years yet). Discussing features simply because they might have been nice but we don't intend to ever add them is utterly pointless IMHO. Aside from D, discussing your dream language is all well and good, but it's not really going to help D if the discussion isn't aimed at improving D as it is now.
 Call the specification D++
 and maybe some day someone will pick it up and try to implement
 it.

Um. That would actually be bad from our point of view. We don't want to fragment the community. D will evolve, and we may even eventually end up with D3, and someone may very well create a D++ someday, but it's not really in our best interest to promote the creation of such a language (especially not now). We want D to succeed, and it's going to have to do that pretty much as it is now. At some point, you have to make what you have work and get it to gain traction in the programming community as it is, or what you have is of little practical value. Forever tweaking it won't get you there even if the tweaks create what is theoretically a better language. So, feel free to air your ideas, but if they're not of practical value towards improving D right now, many of us aren't going to pay much attention to them. - Jonathan M Davis
Oct 01 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 1 October 2012 at 22:47:48 UTC, Timon Gehr wrote:

 A D compiler is also a D interpreter. I wouldn't even bother 
 with D if this wasn't the case.

A D compiler _contains_ a limited interpreter for constant expression evaluation. This has limitations such as not being able to perform IO at compile-time (there's a special pragma for that). This is merely an outgrowth of a compiler optimization technique. Now, back on topic: I agree with Jonathan - in general the compiler can't evaluate _all_ functions at-compile time due these limitations of CTFE and adding a compiler flag will make compilation times far worse than c++. Adding a function attribute adds marginal benefit over simply assigning to a static/enum variable.
Oct 02 2012
prev sibling next sibling parent Don Clugston <dac nospam.com> writes:
On 01/10/12 07:40, Tommi wrote:
 import std.stdio;

 int pow2(int val) pure
 {
      if (__ctfe)
          return 6;
      else
          return val * val;
 }

 void main()
 {
             assert(pow2(3) == 9);
      static assert(pow2(3) == 6);

      writeln("9 = 6 ... I knew it! '6' was faking it all along");
      readln();
 }

You don't need the if (__ctfe) to show this behaviour. Nor do you even need CTFE at all (though it would be a bit less obvious). You could demonstrate it in C++ too. Any code that behaves differently when compiled with -O, will do this as well. Constant folding of floating point numbers does the same thing, if the numbers are represented in the compiler in a different precision to how the machine calculates them. I believe that GCC, for example, uses very much higher precision (hundreds of bits) at compile time.
Oct 02 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Tuesday, 2 October 2012 at 01:00:25 UTC, Walter Bright wrote:
 Since all you need to do to guarantee compile time evaluation 
 is use it in a context that requires CTFE, which are exactly 
 the cases where you'd care that it was CTFE'd, I just don't see 
 much utility here.

I suppose the most common use case would be efficient struct literals which are essentially value types but have non-trivial constructors. struct Law { ulong _encodedId; this(string state, int year) aggressive_ctfe { // non-trivial constructor sets _encodedId // ... } } Policy policy = getPolicy(); if( policy.isLegalAccordingTo(Law("Kentucky", 1898)) ) { // ... } I think the function attribute would be the most convenient solution.
 Note that it is also impossible in the general case for the 
 compiler to guarantee that a specific function is CTFE'able for 
 all arguments that are also CTFE'able.

I'll have to take your word for it for not knowing enough (anything) about the subject.
Oct 04 2012
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 02 Oct 2012 09:38:56 +0200
schrieb Don Clugston <dac nospam.com>:

 Any code that behaves differently when compiled with -O, will do this as 
 well. Constant folding of floating point numbers does the same thing, if 
 the numbers are represented in the compiler in a different precision to 
 how the machine calculates them. I believe that GCC, for example, uses 
 very much higher precision (hundreds of bits) at compile time.

I'm not an expert, but I would have thought compilers strive to be IEEE compliant - whatever that means in detail. I've seen a compression algorithm that relies on exact floating-point semantics and accuracy. It would just fail, if compilers were creative or lax at certain optimization levels. (excluding the "I know what I am doing -ffast-math.) -- Marco
Oct 07 2012