www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How far can CTFE go?

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
I'm experimenting with pluggable expression parser modules, and I'm
wondering if I can use CTFE to build parser tables and such. What are
the current limitations of CTFE? Are dynamic arrays of structs
supported? Associative arrays?  What about compile-time cross-module
initialization?

The idea is to have a library of modules that parse different kinds of
expressions, and depending on which subset of modules are actually
imported into the main program, the capability of the generated parser
will vary. E.g., the basic parser understands only scalar expressions;
import the vector module and it gets extended to handle vector
expressions; import another module and it understands other kinds of
expressions (matrices, etc.).  The parser will be fully specified at
compile-time (I'm not planning to support dynamically loading parsing
modules), so ideally this should be possible to handle using CTFE.

Or is this just a fool's errand?

On another level, how far are we expecting CTFE to go eventually? In my
mind, the ideal situation would be that CTFE can replace writing an
arbitrarily complex helper program that generates D code (either
functions or data, etc.) which then gets incorporated into the main
program.


T

-- 
Guns don't kill people. Bullets do.
Feb 02 2012
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
H. S. Teoh wrote:

 the ideal situation would be that CTFE can replace writing an
 arbitrarily complex helper program

Aebitrary complex helper programs may include viruses and other nice surprises. Walter does not want that adminstrators have to worry about a compilation step to torture the system in such a way. Which restrictions may supress such torture seems unknown. -manfred
Feb 02 2012
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
H. S. Teoh wrote:

 I don't think that should be grounds to get rid of CTFE,
 though.

In contrast to your remark, I do not see the benefits of reducing two compiling phases to one. For me CTFE ist nothing else than running the executables of a first compilation in order to get some values needed for a second compilation. -manfred
Feb 02 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2012 04:26 AM, Manfred Nowak wrote:
 H. S. Teoh wrote:

 I don't think that should be grounds to get rid of CTFE,
 though.

In contrast to your remark, I do not see the benefits of reducing two compiling phases to one. For me CTFE ist nothing else than running the executables of a first compilation in order to get some values needed for a second compilation. -manfred

- needed for a third compilation, needed for a fourth compilation, needed for a fifth compilation ... - better syntax, can do complex things without obfuscating the code - no need to serialize and feed back the data into the compiler - more convenient! - faster - very cool You probably haven't made extensive use of the feature. For me it is the main reason to choose D for development.
Feb 03 2012
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Timon Gehr wrote:

 You probably haven't made extensive use of the feature.

 - needed for a third compilation, needed for a fourth compilation,
 needed for a fifth compilation ...

 - better syntax, can do complex things without obfuscating the
 code 

base, I call that an "obfuscated" base. -manfred
Feb 03 2012
parent Manfred Nowak <svv1999 hotmail.com> writes:
H. S. Teoh wrote:

 If this was code generated by an external utility

argument, that separating code for separatable phases would obfuscate the code.
 for more than one _needed_ phase


there is one, because validation is part of checking contracts, which are not included in the `-release' compilation by definition. -manfred
Feb 04 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2012 12:22 AM, H. S. Teoh wrote:
 I'm experimenting with pluggable expression parser modules, and I'm
 wondering if I can use CTFE to build parser tables and such. What are
 the current limitations of CTFE? Are dynamic arrays of structs
 supported? Associative arrays?  What about compile-time cross-module
 initialization?

 The idea is to have a library of modules that parse different kinds of
 expressions, and depending on which subset of modules are actually
 imported into the main program, the capability of the generated parser
 will vary. E.g., the basic parser understands only scalar expressions;
 import the vector module and it gets extended to handle vector
 expressions; import another module and it understands other kinds of
 expressions (matrices, etc.).  The parser will be fully specified at
 compile-time (I'm not planning to support dynamically loading parsing
 modules), so ideally this should be possible to handle using CTFE.

 Or is this just a fool's errand?

This should work just fine. There is at least one compile-time parser generator for D around, but I cannot find it.
 On another level, how far are we expecting CTFE to go eventually? In my
 mind, the ideal situation would be that CTFE can replace writing an
 arbitrarily complex helper program that generates D code (either
 functions or data, etc.) which then gets incorporated into the main
 program.


 T

It can already do that! mixin(arbitrarily_complex_helper_function());
Feb 03 2012