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.