www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implementing Pure Functions

reply Walter Bright <newshound2 digitalmars.com> writes:
http://drdobbs.com/blogs/tools/230700070

Someone want to post this on reddit?
Jun 16 2011
next sibling parent reply Byakkun <byakkun myopera.com> writes:
On Thu, 16 Jun 2011 12:27:30 +0300, Walter Bright  
<newshound2 digitalmars.com> wrote:

 http://drdobbs.com/blogs/tools/230700070

 Someone want to post this on reddit?

Done http://www.reddit.com/r/programming/comments/i13qp/implementing_pure_functions_in_d_programming/ -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Jun 16 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/16/11 5:02 AM, Byakkun wrote:
 On Thu, 16 Jun 2011 12:27:30 +0300, Walter Bright
 <newshound2 digitalmars.com> wrote:

 http://drdobbs.com/blogs/tools/230700070

 Someone want to post this on reddit?

Done http://www.reddit.com/r/programming/comments/i13qp/implementing_pure_functions_in_d_programming/

This has sparked an interesting discussion, to which I added my bit. Andrei
Jun 16 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 This has sparked an interesting discussion, to which I added my bit.

In D I suggest version(none){} to disable some code :-) Bye, bearophile
Jun 16 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 This has sparked an interesting discussion, to which I added my bit.

int fun(int a) pure { if (a > 10) writeln("I'm impure); } As I understand, even if some calls to a function have some repeatability properties, this doesn't mean the function is pure. In this example fun is obviously impure. Here one can talk about allowing to call impure functions from pure ones, but that's a way different task.
Jun 16 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/17/11 1:56 AM, Kagamin wrote:
 Andrei Alexandrescu Wrote:

 This has sparked an interesting discussion, to which I added my
 bit.

int fun(int a) pure { if (a> 10) writeln("I'm impure); } As I understand, even if some calls to a function have some repeatability properties, this doesn't mean the function is pure. In this example fun is obviously impure. Here one can talk about allowing to call impure functions from pure ones, but that's a way different task.

Right. I gave that example within the context of the discussion, which considered purity a path-sensitive property. By that definition, if fun is provably never invoked with a > 10, then it's effectively pure. Andrei
Jun 16 2011
next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 On 6/17/11 1:56 AM, Kagamin wrote:
 Andrei Alexandrescu Wrote:

 This has sparked an interesting discussion, to which I added my
 bit.

int fun(int a) pure { if (a> 10) writeln("I'm impure); } As I understand, even if some calls to a function have some repeatability properties, this doesn't mean the function is pure. In this example fun is obviously impure. Here one can talk about allowing to call impure functions from pure ones, but that's a way different task.

Right. I gave that example within the context of the discussion, which considered purity a path-sensitive property. By that definition, if fun is provably never invoked with a > 10, then it's effectively pure. Andrei

And that's an interesting thing about CTFE: although it can never do anything impure, it can call impure functions, provided it avoids the impure bits of them: int foo(int n) { static int x = 56; if (n<10) return n; ++x; return x; } static assert(n(5) == 5); Likewise, it can never doing anything unsafe, but can call unsafe functions. bool bar(int n) { if (n < 2) return true; corruptTheStack(); return false; } static assert(bar(1));
Jun 17 2011
parent reply Don <nospam nospam.com> writes:
Byakkun wrote:
 On Fri, 17 Jun 2011 10:49:43 +0300, Don <nospam nospam.com> wrote:
 
 Andrei Alexandrescu wrote:
 On 6/17/11 1:56 AM, Kagamin wrote:
 Andrei Alexandrescu Wrote:

 This has sparked an interesting discussion, to which I added my
 bit.

int fun(int a) pure { if (a > 10) writeln("I'm impure); } As I understand, even if some calls to a function have some repeatability properties, this doesn't mean the function is pure. In this example fun is obviously impure. Here one can talk about allowing to call impure functions from pure ones, but that's a way different task.

which considered purity a path-sensitive property. By that definition, if fun is provably never invoked with a > 10, then it's effectively pure. Andrei

And that's an interesting thing about CTFE: although it can never do anything impure, it can call impure functions, provided it avoids the impure bits of them: int foo(int n) { static int x = 56; if (n<10) return n; ++x; return x; } static assert(n(5) == 5); Likewise, it can never doing anything unsafe, but can call unsafe functions. bool bar(int n) { if (n < 2) return true; corruptTheStack(); return false; } static assert(bar(1));

I was wondering if you could not implement [weak] purity in the language so that it requires the programmer to use contracts to insure that side effects newer happen. I would imagine that this should work with the semantic analysis the compiler provides without adding a specialized theorem prover.

You mean like: int foo(int n) in pure { assert(n < 10); } body { static int x = 56; if (n<10) return n; ++x; return x; } where the 'in pure' contract applies only if the function is called from a pure function?
 (Note: my knowledge of compilers and semantic analysis is fairly limited 
 so ignore this if it is plain stupid).

That'd probably work if the compiler already had a theorem prover -- but it doesn't.
Jun 17 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2011 4:27 AM, Don wrote:
 That'd probably work if the compiler already had a theorem prover -- but it
 doesn't.

I've tried out the theorem prover in Spec#. It only works in trivial cases.
Jun 17 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 I've tried out the theorem prover in Spec#. It only works in trivial cases.

You are beating this horse a bit too much. It uses a quite refined theorem prover, it works, but as I have said from the beginning it doesn't work in all cases. There are always cases automatic provers aren't able to handle. The case you have found is hard. Have you sent them a bug report? Even the one of SPARK doesn't work in all cases. When the one of SPARK doesn't work, then the programmer has to write down the proof manually (or half-manually, with an interactive prover). Bye, bearophile
Jun 17 2011
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 Right. I gave that example within the context of the discussion, which 
 considered purity a path-sensitive property. By that definition, if fun 
 is provably never invoked with a > 10, then it's effectively pure.

That's kinda holistic approach, quite strange thing to see in modern programming. The term "pure function" implies decomposition and definition of purity for parts the program was decomposed to. Usually it's a functional decomposition and in D purity is function-level. I would say that holistic approach is inadequate for notion which is reductionist by its nature.
Jun 17 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 Right. I gave that example within the context of the discussion,

That Reddit page shows your last thoughts about conditional purity too:
We do plan, however, to add purity inference for all template functions because
the source code is by definition available. We believe that that is possible
with a worklist approach. I haven't thought about it a lot, but it seems a
fairly standard analysis. If you think it isn't, let us know before we look
deeper into it! :o)<

The algorithm would be quite powerful I think. It will be an optimistic
analysis that starts with the assumption that a given template function is
pure. Then for each function called by that function, put it in a worklist and
iterate the worklist transitively replacing other functions with the functions
they call, until either an impure function is found or the list is empty. If
the list is empty, then the function is pure. So essentially the algorithm
automatically annotates with "pure" (in the D sense) all template functions
wherever possible. One neat thing is that for a given template function, some
instantiations may be pure and some others may not.<

I presume this recursive algorithm is run only if the template is marked with "pure". The older idea was to let the programmer control, and just add a condition to attributes, using something like optional_tag or just adding the compile time condition beside the pure() attribute, an example: template isPure(F) { enum bool isPure = functionAttributes!(F) & FunctionAttribute.PURE; } pure(isPure!F) int[] map(F)(F f, int[] data) { int[] res; foreach (x; data) res ~= f(x); return res; } We have to keep into account compilation time too. As more and more powerful features are added to the D type system, like this automatic purity, compilation time gets longer. Scala compilation is about ten times slower than Java code (even with the fast fsc compiler), and this makes programming in Scala a little worse in practice. Compilation time matters. Is inferring purity automatically for templates as fast as a pure(CTcondition)? If the programmer uses something like pure(CTcondition) the compiler has to verify the purity of the template anyway, even if the condition is true, but the compiler doesn't need to verify that the template is pure if the CompileTime condition is false. Assuming most code is written correctly, I think this is able to shave away many tests, and save some time to the compiler, reducing compile time a bit. Bye, bearophile
Jun 17 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/17/11 7:01 AM, bearophile wrote:
 Andrei:

 Right. I gave that example within the context of the discussion,

That Reddit page shows your last thoughts about conditional purity too:
 We do plan, however, to add purity inference for all template functions
because the source code is by definition available. We believe that that is
possible with a worklist approach. I haven't thought about it a lot, but it
seems a fairly standard analysis. If you think it isn't, let us know before we
look deeper into it! :o)<

 The algorithm would be quite powerful I think. It will be an optimistic
analysis that starts with the assumption that a given template function is
pure. Then for each function called by that function, put it in a worklist and
iterate the worklist transitively replacing other functions with the functions
they call, until either an impure function is found or the list is empty. If
the list is empty, then the function is pure. So essentially the algorithm
automatically annotates with "pure" (in the D sense) all template functions
wherever possible. One neat thing is that for a given template function, some
instantiations may be pure and some others may not.<

I presume this recursive algorithm is run only if the template is marked with "pure".

No, it would work for all template functions and ran either opportunistically or only as needed.
 The older idea was to let the programmer control, and just add a condition to
attributes, using something like  optional_tag or just adding the compile time
condition beside the pure() attribute, an example:

 template isPure(F) {
      enum bool isPure = functionAttributes!(F)&  FunctionAttribute.PURE;
 }

 pure(isPure!F) int[] map(F)(F f, int[] data) {
      int[] res;
      foreach (x; data)
          res ~= f(x);
      return res;
 }

 We have to keep into account compilation time too. As more and more powerful
features are added to the D type system, like this automatic purity,
compilation time gets longer. Scala compilation is about ten times slower than
Java code (even with the fast fsc compiler), and this makes programming in
Scala a little worse in practice. Compilation time matters.

 Is inferring purity automatically for templates as fast as a
pure(CTcondition)? If the programmer uses something like pure(CTcondition) the
compiler has to verify the purity of the template anyway, even if the condition
is true, but the compiler doesn't need to verify that the template is pure if
the CompileTime condition is false. Assuming most code is written correctly, I
think this is able to shave away many tests, and save some time to the
compiler, reducing compile time a bit.

Automatic inference should not be slower than verification of conditional purity. The work involved is the same. We should do inference for pure, nothrow, const/immutable for any and all template functions. Andrei
Jun 17 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 Automatic inference should not be slower than verification of 
 conditional purity. The work involved is the same.

 No, it would work for all template functions and ran either 
 opportunistically or only as needed.

The first thing you say goes against the second: if you run the verification algorithm even if the template is not tagged with pure, then you are doing more work than running it only on templates tagged as pure. And even if it runs only on templates tagged with pure, I think the compiler is able to do a bit less work if you use pure(CTcond) instead, because the CTcond is chosen by the programmer to be quite discriminating. I guess this can be solved adding some heuristics to the compiler: to test first the most probable places where something impure is (like the functions given as function or template arguments), to prune the impurity search graph faster. In the end I think your idea of automatic purity is better (if it works), because it's more handy for the programmer. But I suggest to add some pruning heuristics, and to run it only on templates tagged with pure. Bye, bearophile
Jun 17 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/17/11 8:39 AM, bearophile wrote:
 Andrei:

 Automatic inference should not be slower than verification of
 conditional purity. The work involved is the same.

 No, it would work for all template functions and ran either
 opportunistically or only as needed.

The first thing you say goes against the second: if you run the verification algorithm even if the template is not tagged with pure, then you are doing more work than running it only on templates tagged as pure.

Well there are two sides of the coin. If you call e.g. a template function from within a pure function, you must do the verification anyway, or refuse to compile if the annotation is missing. Whether or not the annotation is present, the verification work done toward a successful compilation is the same. If anything, the time to a _failed_ compilation may be slower (but not arbitrarily so). On the bright side, inference is great - no more need for the user to bother with annotations, the compiler takes care of it. Furthermore, the compiler may opportunistically infer function attributes (pure, nothrow etc.) if it wants to optimize a specific context.
 And even if it runs only on templates tagged with pure, I think the
 compiler is able to do a bit less work if you use pure(CTcond)
 instead, because the CTcond is chosen by the programmer to be quite
 discriminating.

The downside of that would be not only that the programmer must spend time figuring the right annotation, but also that the result will be suboptimal.
 I guess this can be solved adding some heuristics to
 the compiler: to test first the most probable places where something
 impure is (like the functions given as function or template
 arguments), to prune the impurity search graph faster.

 In the end I think your idea of automatic purity is better (if it
 works), because it's more handy for the programmer. But I suggest to
 add some pruning heuristics, and to run it only on templates tagged
 with pure.

It's Walter's. Templates should not be tagged with pure unless they are pure for all instantiations. Otherwise the annotation would lose any guarantee. Thanks, Andrei
Jun 17 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
bearophile wrote:
 Andrei:

 Automatic inference should not be slower than verification of
 conditional purity. The work involved is the same.

 No, it would work for all template functions and ran either
 opportunistically or only as needed.

The first thing you say goes against the second: if you run the verification

work than running > it only on templates tagged as pure.
 And even if it runs only on templates tagged with pure, I think the compiler is

chosen by
 the programmer to be quite discriminating. I guess this can be solved adding

something impure is > (like the functions given as function or template arguments), to prune the impurity search graph faster.
 In the end I think your idea of automatic purity is better (if it works),

heuristics, and to run > it only on templates tagged with pure.
 Bye,
 bearophile

I think a template tagged with pure should be pure no matter what. Furthermore, I think the additional work required is minimal. The compiler just has to store a flag whether or not any function is pure and set it to false during semantic analysis when it encounters an impure action within the function body. Also, I assume that the bottleneck for compile time is parsing all the (Phobos) imports (that is quite a lot even if you only import one function from one module!). But hopefully local imports are going to improve that situation a lot. (I mean, why exactly do I need to import Eg. std.regex when I do import std.stdio : writeln?) A small problem I can see with the purity validation algorithm proposed by Andrei relates to incremental builds (again): module A; int iampure(){ return 5; } module B; int puretemplate()(){ // inferred pure return iampure(); } int main(){ import std.stdio; writeln(puretemplate(), puretemplate()); // compiler caches result } $ dmd -c A $ dmd -c B $ dmd A.o B.o; ./A 55 Some funny guy decides to change A.iampure: module A; int iampure(){ static int x; return ++x; } $ dmd -c A $ dmd A.o B.o; ./A 11 Wrong! Should be 12. Therefore, the compiler has to assume that functions defined in other modules are not pure unless marked as such. (or issue a pure copy of each would-be-pure function to the object file and call the pure version from inferred pure templates. Then the problem would be detected at link time.) I think the best way to handle it would be to make templates pure iff their body would pass the standard purity validation. Less special casing. Timon
Jun 17 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
On Jun 17, 11 22:41, Timon Gehr wrote:
[snip]
 A small problem I can see with the purity validation algorithm proposed by
Andrei
 relates to incremental builds (again):

 module A;
 int iampure(){
      return 5;
 }

 module B;
 int puretemplate()(){ // inferred pure
      return iampure();
 }

 int main(){
      import std.stdio;
      writeln(puretemplate(), puretemplate()); // compiler caches result
 }

 $ dmd -c A
 $ dmd -c B
 $ dmd A.o B.o; ./A
 55

 Some funny guy decides to change A.iampure:
 module A;
 int iampure(){
      static int x;
      return ++x;
 }

 $ dmd -c A
 $ dmd A.o B.o; ./A
 11

 Wrong! Should be 12.

That happens too if 'iampure' is a template or the compiler inline a function which should be modified, with or without caching. I don't see this as a problem of attribute inference.

 Timon

Jun 17 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
KennyTM~ wrote:
 On Jun 17, 11 22:41, Timon Gehr wrote:
 [snip]
 A small problem I can see with the purity validation algorithm proposed by >
Andrei
 relates to incremental builds (again):

 module A;
 int iampure(){
      return 5;
 }

 module B;
 int puretemplate()(){ // inferred pure
      return iampure();
 }

 int main(){
      import std.stdio;
      writeln(puretemplate(), puretemplate()); // compiler caches result
 }

 $ dmd -c A
 $ dmd -c B
 $ dmd A.o B.o; ./A
 55

 Some funny guy decides to change A.iampure:
 module A;
 int iampure(){
      static int x;
      return ++x;
 }

 $ dmd -c A
 $ dmd A.o B.o; ./A
 11

 Wrong! Should be 12.

That happens too if 'iampure' is a template or the compiler inline a function which should be modified, with or without caching. I don't see this as a problem of attribute inference.

It does not happen if 'iampure' is a template. You get the behavior the template provided before the change (something you understand quickly), not some strange mix based on 'wrong' assumptions of the compiler while performing *implicit* purity inference (which can be hard to track down). There is also no problem with inlining unless you pass -inline when performing incremental builds. Timon
Jun 17 2011
prev sibling parent Byakkun <byakkun myopera.com> writes:
On Fri, 17 Jun 2011 10:49:43 +0300, Don <nospam nospam.com> wrote:

 Andrei Alexandrescu wrote:
 On 6/17/11 1:56 AM, Kagamin wrote:
 Andrei Alexandrescu Wrote:

 This has sparked an interesting discussion, to which I added my
 bit.

int fun(int a) pure { if (a > 10) writeln("I'm impure); } As I understand, even if some calls to a function have some repeatability properties, this doesn't mean the function is pure. In this example fun is obviously impure. Here one can talk about allowing to call impure functions from pure ones, but that's a way different task.

considered purity a path-sensitive property. By that definition, if fun is provably never invoked with a > 10, then it's effectively pure. Andrei

And that's an interesting thing about CTFE: although it can never do anything impure, it can call impure functions, provided it avoids the impure bits of them: int foo(int n) { static int x = 56; if (n<10) return n; ++x; return x; } static assert(n(5) == 5); Likewise, it can never doing anything unsafe, but can call unsafe functions. bool bar(int n) { if (n < 2) return true; corruptTheStack(); return false; } static assert(bar(1));

I was wondering if you could not implement [weak] purity in the language so that it requires the programmer to use contracts to insure that side effects newer happen. I would imagine that this should work with the semantic analysis the compiler provides without adding a specialized theorem prover. (Note: my knowledge of compilers and semantic analysis is fairly limited so ignore this if it is plain stupid). -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Jun 17 2011
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Walter Bright Wrote:

 http://drdobbs.com/blogs/tools/230700070

import std.stdio; int square_debug(int x) { writefln("square(%d)", x); return x * x; } pure alias int function(int) fp_t; pure int square(int x) { auto fp = cast(fp_t)&square_debug; return (*fp)(x); // dereference??? }
Jun 16 2011
parent reply Jimmy Cao <jcao219 gmail.com> writes:
--0016e640d1e0b49a1c04a5d276e1
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 16, 2011 at 6:07 AM, Kagamin <spam here.lot> wrote:

 Walter Bright Wrote:

 http://drdobbs.com/blogs/tools/230700070

import std.stdio; int square_debug(int x) { writefln("square(%d)", x); return x * x; } pure alias int function(int) fp_t; pure int square(int x) { auto fp = cast(fp_t)&square_debug; return (*fp)(x); // dereference??? }

Yes, that's correct. --0016e640d1e0b49a1c04a5d276e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 16, 2011 at 6:07 AM, Kagamin <span dir=3D"ltr">&lt;spam here.lo= t&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex;"> <div class=3D"im">Walter Bright Wrote:<br> <br> &gt; <a href=3D"http://drdobbs.com/blogs/tools/230700070" target=3D"_blank"=
http://drdobbs.com/blogs/tools/230700070</a><br>

</div>import std.stdio;<br> <br> int square_debug(int x)<br> {<br> =A0 =A0writefln(&quot;square(%d)&quot;, x);<br> =A0 =A0return x * x;<br> }<br> <br> pure alias int function(int) fp_t;<br> <br> pure int square(int x)<br> {<br> =A0 =A0auto fp =3D cast(fp_t)&amp;square_debug;<br> =A0 =A0return (*fp)(x); // dereference???<br> }<br> </blockquote></div><br><div>Yes, that&#39;s correct.</div> --0016e640d1e0b49a1c04a5d276e1--
Jun 16 2011
parent reply Kagamin <spam here.lot> writes:
Jimmy Cao Wrote:

 pure int square(int x)
 {
    auto fp = cast(fp_t)&square_debug;
    return (*fp)(x); // dereference???
 }

Yes, that's correct.

You mean, implementation-defined?
Jun 16 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2011 5:27 AM, Kagamin wrote:
 Jimmy Cao Wrote:

 pure int square(int x)
 {
     auto fp = cast(fp_t)&square_debug;
     return (*fp)(x); // dereference???
 }

Yes, that's correct.

You mean, implementation-defined?

It's typed as pointing to a pure function. So, it's callable from a pure function.
Jun 16 2011
parent reply Kagamin <spam here.lot> writes:
Walter Bright Wrote:

 You mean, implementation-defined?

It's typed as pointing to a pure function. So, it's callable from a pure function.

I mean that function pointers are not documented to allow dereference operator, that's why behavior of your code is implementation-dependent. You spend too much time writing in C++.
Jun 16 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2011 11:59 PM, Kagamin wrote:
 I mean that function pointers are not documented to allow dereference
 operator, that's why behavior of your code is implementation-dependent. You
 spend too much time writing in C++.

I don't know what you mean.
Jun 17 2011
parent KennyTM~ <kennytm gmail.com> writes:
On Jun 17, 11 15:32, Walter Bright wrote:
 On 6/16/2011 11:59 PM, Kagamin wrote:
 I mean that function pointers are not documented to allow dereference
 operator, that's why behavior of your code is
 implementation-dependent. You
 spend too much time writing in C++.

I don't know what you mean.

You should call the function pointer as return fp(x); not return (*fp)(x);
Jun 17 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

Thanks to Andrei Alexandrescu, Brad Roberts, David Held, and Bartosz Milewski
for their helpful comments and corrections on this post.<

*pulls Walter's ears* You have forgotten who has found this problem :-) Bye, bearophile
Jun 16 2011
parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Walter:
 
 Thanks to Andrei Alexandrescu, Brad Roberts, David Held, and Bartosz Milewski
for their helpful comments and corrections on this post.<

*pulls Walter's ears* You have forgotten who has found this problem :-)

So have I. It was mentioned at the start of 2008 with respect to pure, but the same problem was mentioned with regard to CTFE much earlier, in 2006 I think. I think Daniel Keep was the first to mention it.
Jun 16 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2011 6:29 AM, Don wrote:
 bearophile wrote:
 Walter:

 Thanks to Andrei Alexandrescu, Brad Roberts, David Held, and Bartosz Milewski
 for their helpful comments and corrections on this post.<

*pulls Walter's ears* You have forgotten who has found this problem :-)

So have I. It was mentioned at the start of 2008 with respect to pure, but the same problem was mentioned with regard to CTFE much earlier, in 2006 I think. I think Daniel Keep was the first to mention it.

The acknowledgments did not attempt to credit where the idea came from, just the people who made comments on a draft of that post. This thread is particularly relevant: http://www.digitalmars.com/d/archives/digitalmars/D/Temporarily_disable_all_purity_for_debug_prints_134460.html As for the problem, which is doing I/O in a pure function, that goes back decades.
Jun 16 2011