It doesn't make sense to talk of value as a location. A value is a piece of data, plain and simple. So lvalues and objects aren't values.
OTOH, I can agree with the imperative programmer's intuition of a variable as a location where you can store a value (rather than a symbol that can be consistently substituted with a value). It's not a mathematical variable, but it's a sufficiently established meaning to be taken into consideration in serious discussion. (Furthermore, the connection between imperative variables and mathematical variables can be restored using Hoare logic.)
>It doesn't make sense to talk of value as a location. A value is a piece of data, plain and simple. So lvalues and objects aren't values.
It doesn't have to make sense (I think it makes perfect sense, but that's neither here nor there): people do it, and the default assumed definition of a value is broad enough that it allows for it, IME.
I don't object to your definition, but can you please just tell everybody what you mean by value in your comment if it's not what people expect, so that people like me don't have to build a deeply nested discussion thread to establish what you mean?
If I was sure of its legality by the rules of HN, I'd be lf half a mind actually write a bot to insert the definition below your posts, and save people a lot of time trying to ascertain what you mean, so the we could all have a more interesting discussion about the ideas, rather than the terminology.
Oh, sorry. I was implicitly making the following assumptions:
(0) Reactions can be quantified - assigned numerical values, roughly corresponding to our intuition of a “positive”, “neutral” or “negative” reaction.
(1) The possible reactions can be meaningfully averaged, and the result can be interpreted as a reaction value as well.
So by “expectation”, I meant “expected value”, in the usual sense. If your objection is that “expectation” can't be used as this, I have evidence that suggests otherwise:
It's rather non-standard to say "I expected" in this sense but since you've gone to the trouble to define your terminology and back up your claim, fair enough!
Yeah, to clarify, my initial gripe was that he didn't clarify his terminology to begin with. His definition is correct, it's just uncommon, and confusing as a result. He really should have clarified this in the head comment.
If you're going to argue here about programming languages terminology it behooves you get terminology from other fields correct.