View mode: basic / threaded / horizontal-split · Log in · Help
October 01, 2012
It seems pure ain't so pure after all
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();
}
October 01, 2012
Re: It seems pure ain't so pure after all
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
October 01, 2012
Re: It seems pure ain't so pure after all
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)"
October 01, 2012
Re: It seems pure ain't so pure after all
On Monday, October 01, 2012 07:43:59 Alex Rønne Petersen wrote:
> 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.

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.

int func(int val) pure
{
   version(linux)
       return val + 2;
   else version(Windows)
       return val + 3;
}

- Jonathan M Davis
October 01, 2012
Re: It seems pure ain't so pure after all
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
October 01, 2012
Re: It seems pure ain't so pure after all
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();
}
October 01, 2012
Re: It seems pure ain't so pure after all
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.
October 01, 2012
Re: It seems pure ain't so pure after all
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
October 01, 2012
Re: It seems pure ain't so pure after all
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.
October 01, 2012
Re: It seems pure ain't so pure after all
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home