3 ms·
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 ei
by Shoop 10y ago
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.
- steveklabnik 10y ago> 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.
- wtetzner 10y agoAnd Common Lisp, and Scheme, and Elixir, and Clojure, and I'm sure I'm missing a bunch :)
- p0nce 10y agoThose come with the whole compiler at runtime.
- lomnakkus 10y agoEven... 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).
- Zardoz84 10y agoCompile 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 agoI 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 agoThe 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 agoHow 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 agoCompile 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 agoSome 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.