Hacker News Reader

Comment by Zardoz84 | Hacker News Reader

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.

View on HN

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

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.

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.

How is it any different from, say, a makefile?

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?)

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.

Perl source filters

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?

Reply on news.ycombinator.com