How far can CTFE go?

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Feb 3 17:21:10 PST 2012


On Sat, Feb 04, 2012 at 01:54:55AM +0100, Timon Gehr wrote:
[...]
> >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.
[...]
> 
> It can already do that!
> 
> mixin(arbitrarily_complex_helper_function());
[...]

Yes, but how complete is the support for this? Last I checked, I
couldn't call floating-point functions in the helper function 'cos
std.math apparently uses asm to implement some of the math functions,
and gdc refuses to evaluate that at compile-time.

And IIRC, TDPL does mention that certain language constructs can't be
used due to compiler limitations. (I'll have to look that up again when
I get home.)

But my original question pertains to cross-module initialization. Can
the following can be achieved?:

- The parser module (or parser generator module as the case may be)
  needs to collect info for all modules to be included in the final
  parser so that it can generate tables used by the parsing engine.

- Ideally, the act of compiling one of these pluggable modules should
  automatically include itself into the parsing tables.

- The tables should ideally be fully computed at compile-time.

The main challenge is, how to have the pluggable module inform the
parser module of its presence *at compile time*? Ideally, the parser
module shouldn't need to keep a big list of potential modules; it should
be the modules that register themselves with the parser. This is easily
done with a static init method, obviously, but the challenge is how to
achieve this at compile time.

One way I can think of is for the module that contains main() decide
which modules it wants to include, and call the parser module's setup
function via CTFE with the list of modules it should lookup. So then the
question becomes, given a list of modules represented as strings, is it
possible for CTFE to do symbol lookups of that module at compile-time?

This seems as far as I can go, at least from what I know. It would be
nice if the main module doesn't even need to pass a list of modules to
the parser generator, just link the relevant modules, and have the
parser generator automatically detect what modules are present. But I
suspect that won't work 'cos by the time we get to the linker it's too
late to know which modules were included.


T

-- 
Don't throw out the baby with the bathwater. Use your hands...


More information about the Digitalmars-d-learn mailing list