www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CTFE: What limitations remain?

reply dsimcha <dsimcha yahoo.com> writes:
The documentation for CTFE is outdated and specifies limitations that no
longer exist thanks to Don's massive overhaul.  For example, a big one is that
pointers now work.  What limitations that could potentially be removed still
do exist in CTFE as of 2.054?
Jul 12 2011
next sibling parent d coder <dlang.coder gmail.com> writes:
For example, a big one is that

 pointers now work.



Do function pointers work?
Jul 12 2011
prev sibling next sibling parent Johann MacDonagh <johann.macdonagh..no spam..gmail.com> writes:
On 7/12/2011 10:22 AM, dsimcha wrote:

 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one is that
 pointers now work.  What limitations that could potentially be removed still
 do exist in CTFE as of 2.054?


Right now I'm up against two limitations:
http://d.puremagic.com/issues/show_bug.cgi?id=4046
http://d.puremagic.com/issues/show_bug.cgi?id=6268

That being said, I am amazed at what I can get away with now with
CTFE. I find myself saying "there's no way I can do that", then
testing out with enum x = theresNoWay(); and being amazed at the clean
compile.
Jul 12 2011
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 12.07.2011 18:22, dsimcha wrote:

 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one is that
 pointers now work.  What limitations that could potentially be removed still
 do exist in CTFE as of 2.054?


Just hited all of the below:
     - try/catch
     - intrinsics (bsr, bsf etc. ) this currently also means no Appender
     - array.reserve
     - foreach over tupple (aka static foreach)

-- 
Dmitry Olshansky
Jul 12 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 13 Jul 2011 02:32:41 -0400, Dmitry Olshansky  
<dmitry.olsh gmail.com> wrote:


 On 12.07.2011 18:22, dsimcha wrote:

 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one  
 is that
 pointers now work.  What limitations that could potentially be removed  
 still
 do exist in CTFE as of 2.054?


 Just hited all of the below:
      - try/catch
      - intrinsics (bsr, bsf etc. ) this currently also means no Appender


Don has a patch for appender that allows it to work during CTFE:  
https://github.com/D-Programming-Language/phobos/pull/129

Actually, that was merged, prior to 2.054 release, may want to try  
appender again ;)


      - array.reserve


array.reserve is specific to the GC, and the GC isn't the same during  
compile time.  Asking for this is like asking for GC.malloc.

However, if there ever was a working D compiler written in D, these kinds  
of things could be done no problem.  Reserve does seem like a useful thing  
to allow during CTFE.

Of course, I could change reserve to simply do nothing during ctfe, which  
would make things "work", even though reserving wasn't actually  
happening...


      - foreach over tupple (aka static foreach)
Jul 13 2011
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 13.07.2011 16:43, Steven Schveighoffer wrote:

 On Wed, 13 Jul 2011 02:32:41 -0400, Dmitry Olshansky 
 <dmitry.olsh gmail.com> wrote:


 On 12.07.2011 18:22, dsimcha wrote:

 The documentation for CTFE is outdated and specifies limitations 
 that no
 longer exist thanks to Don's massive overhaul.  For example, a big 
 one is that
 pointers now work.  What limitations that could potentially be 
 removed still
 do exist in CTFE as of 2.054?


 Just hited all of the below:
      - try/catch
      - intrinsics (bsr, bsf etc. ) this currently also means no Appender


 Don has a patch for appender that allows it to work during CTFE: 
 https://github.com/D-Programming-Language/phobos/pull/129

 Actually, that was merged, prior to 2.054 release, may want to try 
 appender again ;)


And I thought I was on a bleeding edge dmd, apparently I'm too slow to 
pull these in time  :)


      - array.reserve


 array.reserve is specific to the GC, and the GC isn't the same during 
 compile time.  Asking for this is like asking for GC.malloc.

 However, if there ever was a working D compiler written in D, these 
 kinds of things could be done no problem.  Reserve does seem like a 
 useful thing to allow during CTFE.

 Of course, I could change reserve to simply do nothing during ctfe, 
 which would make things "work", even though reserving wasn't actually 
 happening...


I'd say that would be an adequate workaround.


      - foreach over tupple (aka static foreach)




Ok, so of all above try/catch is the last big thing.

-- 
Dmitry Olshansky
Jul 13 2011
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
dsimcha wrote:

 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one is that
 pointers now work.  What limitations that could potentially be removed still
 do exist in CTFE as of 2.054?


I rewrote the documentation for CTFE, it's been in the docs on github 
for several weeks but apparently didn't get into the download???
(I went on holidays before the beta was released, so I wasn't able to 
check it).
Jul 20 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2011 1:59 PM, Don wrote:

 I rewrote the documentation for CTFE, it's been in the docs on github for
 several weeks but apparently didn't get into the download???
 (I went on holidays before the beta was released, so I wasn't able to check
it).


I don't see it here?

https://github.com/D-Programming-Language/d-programming-language.org/pulls
Jul 20 2011
prev sibling parent reply Don <nospam nospam.com> writes:
dsimcha wrote:

 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one is that
 pointers now work.  What limitations that could potentially be removed still
 do exist in CTFE as of 2.054?


The updated CTFE documentation is here:
http://d-programming-language.org/function.html
Jul 25 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Don:


 The updated CTFE documentation is here:
 http://d-programming-language.org/function.html



 3. the following statement types are not allowed:
 * with statements


I hope this 'with' limitation is temporary :-)

------------------------

Regarding that whole page:

I think the section about purity doesn't say that __ctfe is allowed in pure
functions.

------------------------


Cyclic functions (i.e. functions that wind up directly or indirectly calling
themselves) are inferred as being impure, throwing, and  system.<


I didn't know/remember this. Is this done to simplify the analysis?


int fact(T)(in T n) {
    return n ? (n * fact(n-1)): 1;
}
void main() pure {
    auto x = fact(5);
}

------------------------


Attribute inference is not done for other functions, even if the function body
is present.<


In D.learn I have shown an idea: to infer only the purity of functions called
by templates, to allow more templates to be pure; and such inferred purity is
seen by function templates only.

Example: if a impure function sqr() is called by both an impure function
template bar() and by a pure function foo(), the compiler raises an error in
foo(), because sqr() is not pure, but compiles the pure main() because sqr()
called by bar() is seen as pure :-)


int sqr(in int x) {
     return x * x;
}
int foo(in int x) pure { // error, sqr is not tagged pure
     return sqr(x) + sqr(x);
}
int bar(T)(in T x) {
     return sqr(x) * sqr(x);
}
void main() pure {
     bar(1); // OK, sqr can be inferred as pure
}


But it seems a bit complex for the final programmer too (and maybe it needs a
one level deeper purity inference).

Bye,
bearophile
Jul 25 2011