I'm trying to understand what you are suggesting with your response, especially because what I ultimately want to do in this instance I will want to do with other bigger generators.
What I assume you are saying is `helper` is some Nim source program that will produce the output that `gemPGparameters` does. The expression you give will then execute `helper` at run time and provide its results to `const parameters` at its compile time. Is this interpretation correct? What I ultimately want to do is create a family of `const parameters` for different prime generators at compile time. Then when the program executes it will select which parameters to use based on the input value. For P17 the `residues` array has 92,160 values, P19 has 1,658,880, P23 has 36,495,360. So I ultimately want a lot of values computed and stored at compile time. Your response suggests the current compiler won't accommodate this amount of data generation at compile time. I guess my question is why? Why not create a compiler directive to remove any time/data constraints to compile time activity? Make the compiler do what the programmer wants. Also, just from your response I don't have enough detailed information to make your suggestion work. Is this suggestion verified to provide the results I want? If so, can you give a detailed example of how to implement it? I understand Nim is still young and in core fundamental development, so I hope you take this situation into consideration for future compiler development. I've been able to do a lot with Nim as it is (and I understand it), so these improvements will greatly extend its usefulness to the class of problems I am now working on. Thanks for taking this into consideration.
