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