View mode: basic / threaded / horizontal-split · Log in · Help
October 01, 2012
Re: It seems pure ain't so pure after all
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
October 01, 2012
Re: It seems pure ain't so pure after all
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
October 01, 2012
Re: It seems pure ain't so pure after all
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
October 01, 2012
Re: It seems pure ain't so pure after all
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.
October 01, 2012
Re: It seems pure ain't so pure after all
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.
October 01, 2012
Re: It seems pure ain't so pure after all
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
October 01, 2012
Re: It seems pure ain't so pure after all
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/
October 01, 2012
Re: It seems pure ain't so pure after all
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
October 01, 2012
Re: It seems pure ain't so pure after all
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?
October 01, 2012
Re: It seems pure ain't so pure after all
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).
1 2 3 4 5 6
Top | Discussion index | About this forum | D home