4 ms·

Compile time read have sense. For example, reading a XML to build a GUI on complete time instead on runtime (I see you GTK builder). Actually you can do this o

Compile time read have sense. For example, reading a XML to build a GUI on complete time instead on runtime (I see you GTK builder). Actually you can do this on CTFE on D, doing an import of a file and dumping it to an enum. The only big pitfall of this, is that enforces to read the whole file by the compiler.

Shoop 10y ago
I withdraw my claim that compile time IO doesn't make any sense, but it is something I would be worried about. I wouldn't want the executable my build process produces to be changed by what files are laying around on the disk. Mixing in all of the state in the file system with something you want to be mostly stateless (your build process) seems like a dangerous idea to me.
- dansze 10y ago
  The compiler already depends on the state of the file system though, notably because it depends on the source code. In the above case, the xml is essentially just another source file that happens to not be in the same language. An important difference is that the compiler doesn't know it's using that file ahead of time, which could have some unforeseen consequences, but I don't see anything immediately worrying about that fact since the compiler didn't know about the source either at it's own compile time.
- duaneb 10y ago
  How is it any different from, say, a makefile?
p0nce 10y ago
> reading a XML to build a GUI on complete time instead on runtime It can be done with: void[] ctData = import("file.xml"); For example, this feature is used in vibe.d to compile an HTML template language into more optimized code.
stcredzero 10y ago
Compile time read have sense. Considering what we've known about the typical behavior of production programs for decades, why isn't there also an "Initialization Time" in addition to Compile Time and "runtime." (Steady State Time?)
- steveklabnik 10y ago
  Some languages do have a "life before main", but it's not always clear that it's a good thing. I don't have a link offhand, but I think it has a bad rap because it's often used to initialize some kind of global state, with all the cons global state brings.
  - ptman 10y ago
    Perl source filters
  - stcredzero 10y ago
    I remember a study of production Python servers that showed that past an "initialization period" the types of objects in variables settled down and essentially became static. It seems to me that this is a very common across many languages, and that this pattern could be exploited in a number of ways. (Compiling "dynamic" languages in the above case.) I think it has a bad rap because it's often used to initialize some kind of global state, with all the cons global state brings. So then what if the language didn't have global state, or only had immutable global state?

Shoop 10y ago

I withdraw my claim that compile time IO doesn't make any sense, but it is something I would be worried about. I wouldn't want the executable my build process produces to be changed by what files are laying around on the disk. Mixing in all of the state in the file system with something you want to be mostly stateless (your build process) seems like a dangerous idea to me.

dansze 10y ago
The compiler already depends on the state of the file system though, notably because it depends on the source code. In the above case, the xml is essentially just another source file that happens to not be in the same language. An important difference is that the compiler doesn't know it's using that file ahead of time, which could have some unforeseen consequences, but I don't see anything immediately worrying about that fact since the compiler didn't know about the source either at it's own compile time.
duaneb 10y ago
How is it any different from, say, a makefile?

p0nce 10y ago

> reading a XML to build a GUI on complete time instead on runtime It can be done with: void[] ctData = import("file.xml"); For example, this feature is used in vibe.d to compile an HTML template language into more optimized code.

stcredzero 10y ago

Compile time read have sense. Considering what we've known about the typical behavior of production programs for decades, why isn't there also an "Initialization Time" in addition to Compile Time and "runtime." (Steady State Time?)

steveklabnik 10y ago
Some languages do have a "life before main", but it's not always clear that it's a good thing. I don't have a link offhand, but I think it has a bad rap because it's often used to initialize some kind of global state, with all the cons global state brings.
- ptman 10y ago
  Perl source filters
- stcredzero 10y ago
  I remember a study of production Python servers that showed that past an "initialization period" the types of objects in variables settled down and essentially became static. It seems to me that this is a very common across many languages, and that this pattern could be exploited in a number of ways. (Compiling "dynamic" languages in the above case.) I think it has a bad rap because it's often used to initialize some kind of global state, with all the cons global state brings. So then what if the language didn't have global state, or only had immutable global state?