Re:Ruminations on D: An Interview with Walter Bright
by p0nce on Tuesday August 30, 2016 @06:34PM
(#12394504)
> reading a XML to build a GUI on complete time instead on runtime
It can be done with:
void[] ctData = import("file.xml");
Re:Ruminations on D: An Interview with Walter Bright
by Shoop on Tuesday August 30, 2016 @01:11PM
(#12391914)
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.
Re:Ruminations on D: An Interview with Walter Bright
by dansze on Tuesday August 30, 2016 @01:24PM
(#12392022)
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.
Re:Ruminations on D: An Interview with Walter Bright
by duaneb on Tuesday August 30, 2016 @02:51PM
(#12392802)
How is it any different from, say, a makefile?
Re:Ruminations on D: An Interview with Walter Bright
by stcredzero on Tuesday August 30, 2016 @07:48PM
(#12394877)
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?)
Re:Ruminations on D: An Interview with Walter Bright
by steveklabnik on Tuesday August 30, 2016 @08:22PM
(#12395024)
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.
Re:Ruminations on D: An Interview with Walter Bright
by stcredzero on Wednesday August 31, 2016 @02:12PM
(#12400273)
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?
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.