On Thursday, 13 August 2015 at 09:52:02 UTC, JDemler wrote:
This solves the concurrency problem. But what about non concurrent compiler runs? A block there would never be resolved. I do not know enough about compilers to judge this problem. Can a sane way of compiling the files be found easily? Can the compiler switch to compile something else when it is blocked on an import?

You need a highly concurrent compiler. If you import in one definition and export in the next definition, then the first one would block and be queued, and the compiler would move on to the next definition.

In the actor-model (co-routines/fibers) each definition will spawn a new actor.

And I do not understand why you differentiate between generated source files and generated non source files (.xml, .ini). As both types can be imported (or read at compile time) I do not think we should treat them differently. Also we would need a way to tell the one from the other (file extension? different parameter in the export syntax?).
In my understanding storage area 2 and 3 should be merged.

Area 2 is pre-populated with area 1, so they are the same.

You need to be able to tell the compiler what files should be included in the output bundle.

Actually, I think the file-model is too simple. I think you need a more advanced key-value database so that you can update different fields in the same ".ini file" from different source files.

Reply via email to