• "H. S. Teoh" <hsteoh quickfur.ath.cx> Feb 02 2012
• Manfred Nowak <svv1999 hotmail.com> Feb 02 2012
• Manfred Nowak <svv1999 hotmail.com> Feb 02 2012
• Timon Gehr <timon.gehr gmx.ch> Feb 03 2012
• Manfred Nowak <svv1999 hotmail.com> Feb 03 2012
• Manfred Nowak <svv1999 hotmail.com> Feb 04 2012
• Timon Gehr <timon.gehr gmx.ch> Feb 03 2012

"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.

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

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

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.

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

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

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());