Lambda the Ultimate

literals vs. named constants...

By my understanding, languages that generally are compiled directly to machine code (actual CPU instructions), tend to be used for tasks where maximum speed is (more/most) important, so constants are usefull for them - in source they allow extra abstraction, and are implemented as defined values themselves or pointers to them - accessing those could take quite (an order of magnintude, in worst case) less time than executing some function that would return same value or pointer. On the other hand, languages that are (semi-?)interpreted (albeit nowadays I doubt a strict line can be drawn between "interpreted" and "compiled"), actual access times for constant or call would be more equal, hence the question for usefulness.

Abit of oftopic: Isn't my english too cluttered? It is not my first language and I am not very versed in writing in it.

I'd have guessed English was your first language. You write it better than an average American speaker on tech subjects. Your verb declensions and phrasing are very good and natural (better than most English speakers manage in tech subjects with long sentences). Other than a couple typos (extra 'l' after useful, missing 'f' in off topic) the last post looks about perfect.

By the way, I'm interested in this discussion of constants, but don't have much to add right now.

I thought this is what you had in mind. I think your analysis is based on some problematic assumptions. But I'll just concentrate on the most general issues for now.

1. You can expect any decent compiler to be able to optimize and inline function calls to simple functions such as these, so x=4 and x=f() with f={return 4} should be lead to identical machine code.

2. Interpreters are more likely to be limited in their whole-program analysis and optimization (though this is an over-generalization), so in fact the cost of function calls in this scenario will be greater than in the compile code case. Since interpreted implementations are usually slower, and since speed is always an issue (even when performance isn't the main concern), the cost of your approach here is probably going to be more noticeable and the pressure to avoid it greater.

The more general issues are as follows: (1) Compiled languages are not used only when "maximum speed" is important. Moreover, when speed is important, the cost of function calls is usually marginal, and especially if we restrict our attention to the few places in which named constants are used. Not all systems have real-time constraints. (2) The crucial issue is whether you (and the compiler) can rely on the fact that the function will always return the same value. This is crucial for optimization, as well as for reasoning about the code. Whether you know this ultimately depends on the semantics of the language (pure/impure), type system issues etc.

Quite right, of course. But if you model constants as functions, you are guaranteed that these functions are free of side-effects.

um, question is not about whether constant-ish things (some "name" mapped to "constant value") are usefull, but on that if (and why) they are needed as a seperate component of language.

anyways - about "Reader comprehension" - in my language (same goes for most of other languages I am familiar with) function names can be "all caps and underscores" -MAXIMUM_LOGIN_ATEMPTS().
and on "Configuration management" - again - there is no reason why I could not define all configuration related functions in one place, and use them througout my program.

My apologies for being too hasty and missing the point. The same logic I (mis)applied before is still relevant.

Unifying "const" values with zero-argument functions lets you change the complexity of a policy (e.g. MaximumLoginAttempts) without consequence to the usage sites, which seems a good thing. (I think this is independent of whether the language implementation is performance-obssessed or not. ;-)

FWIW, Scala also follows this Uniform Access Principle.

Scala is a worthy model in regards to making access to value members and function members look the same even at the generated code level, but I wouldn't say it unifies values with nullary functions.

object Constants {
  val valConstant = {println("evaluating a value"); 42}
  def funcConstant = {println("evaluating a function"); 42}
}

The expression for valConstant will only be evaluated once - your console will only see "evaluating a value" once. The expression for funcConstant will be evaluated every time funcConstant is called in your program execution - you'll see "evaluating a function" in the console arbitrarily many times.

Which was the point I was trying to make above (perhaps unsuccessfully).

I'm not sure if this is what Joel was referring to, but Scala does unify direct field access and getter/setter functions. Field access is compiled down to a function call to a trivial "getter" method. If you want to provide a fancier method later, you can do so without breaking ABI compatibility.

You're quite right that access to "fields" is via automatically generated methods.

But if I understand the OP's question it was "why would a language need a distinct concept (syntactically or semantically) for 'constants'". Scala certainly does, and hopefully my code showed why. Also worth noting is that Scala has "lazy vals" which are basically memoized nullary functions. Still distinct from ordinary nullary functions which are evaluated on each use and "vals" which are evaluated at object construction.

No, my language is not pure. Out of curiosity I just looked up "pure procedural language", and it appears that "pure" for procedural languages (and mine is procedural) means there are no functions per se (- and no arguments, which implies only one variable scope - global one) - it's just GOSUBs and RETURNs all the way to the bottom. I intend to have my functions.
The main reason I am considering "unifying constants with functions" (e.g.. not implementing them at all) is because I am not sure if it's worth doing it, for simplicity's sake.

I did not know about the notion of a purely procedural language. I used that term in the sense it would be used when speaking of a pure functional language.

My question was really, why don't you unify constants with variables instead of functions?