News for hackers. Stuff that matters.
Re:Ruminations on D: An Interview with Walter Bright by Shoop on Tuesday August 30, 2016 @12:42PM (#12391658)
If inline asm or non-portable casts were allowed, D programs would compile inconsistently on different architectures. Compile time IO doesn't make much sense either. Not all limitations are shortcomings.
Re:Ruminations on D: An Interview with Walter Bright by Zardoz84 on Tuesday August 30, 2016 @12:58PM (#12391802)
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.

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");
For example, this feature is used in vibe.d to compile an HTML template language into more optimized code.
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?

Re:Ruminations on D: An Interview with Walter Bright by ptman on Wednesday August 31, 2016 @06:47AM (#12397318)
Perl source filters
Re:Ruminations on D: An Interview with Walter Bright by steveklabnik on Tuesday August 30, 2016 @12:58PM (#12391798)

  > Compile time IO doesn't make much sense either.
While I agree with D's decision here, there are other languages which do allow anything at compile time. See Jai, for example.
Re:Ruminations on D: An Interview with Walter Bright by wtetzner on Tuesday August 30, 2016 @03:56PM (#12393341)
And Common Lisp, and Scheme, and Elixir, and Clojure, and I'm sure I'm missing a bunch :)
Re:Ruminations on D: An Interview with Walter Bright by lomnakkus on Wednesday August 31, 2016 @04:04PM (#12401078)
Even... Haskell! Dundundun! (I'm referring to Template Haskell.)

As it turns out (IME) referencing arbitrary data (such as a database schema queried from a 'live' database) is actually of quite limited value.

Where I actually agree that it makes sense is the 'read-a-checked-in-file-and-generate-code-at-compile-time-from-that'. Otherwise, you're mostly just looking at a lot of pain compared to just generating code (that you might check in).

Re:Ruminations on D: An Interview with Walter Bright by p0nce on Tuesday August 30, 2016 @06:35PM (#12394508)
Those come with the whole compiler at runtime.