On Tuesday, July 20, 2010 06:36:57 Justin Johansson wrote: > Perhaps this is a philosophical question, like what is time, though it > is also a novice programmer question as well. The question exactly > being: > > "What is the difference between a (constant/immutable) value and the > result of calling a side-effect free function that returns the same?" > > May I please petition respondents not to answer in terms of PL syntax. > That is, this question is not about optional parentheses which some > PL's use to make values and nullary function calls look syntactical > alike. > > Going beyond syntax and into semantics, does the D language have > any special "opinion" or idiom relating to constant/immutable > values versus nullary function calls? > > From my observation, the Scala PL community has had similar questions > poised in the past (about the difference between val's and nullary > functions) and their answer has largely given into constraints > imposed upon Scala's implementation and semantics as are > implementable on the Java Virtual Machine (JWM). > > Thanks for answers, > Justin Johansson
1. A const variable is a chunk of memory which can be read as a particular type but not written to in that context. Optimizations may remove it in some cases. 2. An immutable variable is a chunk of memory which can be read as a particular type and cannot be written to in any context. Optimizations may remove it in some cases (and likely more cases than with const). 3. A manifest constant using an enum is a value of a particular type which is reused throughout the code without being an addressable chunk of memory (though it may still actually have an address depending on what the compiler does - you just can't address it yourself). The value never changes and cannot be changed. 4. A pure function which takes no parameters and simply returns a value of a particular type is not a chunk of memory. It's a procedure at a certain location in memory, which is therefore addressable for the purposes of calling it (or passing it around to be called). When it is run, it produces a value, and it will always produce the same value regardless of when it is run. Optimizations may remove the call in some cases and simply re-use the result. Also, the function could be used in CTFE to produce the value at compile time and just use that value instead of calling the function at runtime. Depending on how the function is used and how much optimizing the compiler does, the function may never get called at runtime. But it is ultimately a function rather than a variable, which means that it is used as a function, including what that means for addressing it. So, there _will_ be cases where it cannot be optimized out (like if you're passing around a pointer to it and calling it through the pointer). It is _not_ a variable. It may get optimized to the point that it's as efficient as a variable, but then again, it might not be. And there are cases where it acts very much like the function that it is. - Jonathan M Davis