It wasn't meant to be correct... That's the whole point.
"What we've got here, is a failure to communicate."
Your definition of a "value" seems to be a strictly immutable, functional-oriented definition. Which is fine; that's a valid definition and there's nothing wrong with it. The issues come from the fact that you seem to refuse to accept that that is one definition of many, and continue to push it without compromise.
It's correct only using your definitions and axioms. Other definitions and axioms can and do come to other conclusions. Your refusal to acknowledge that other definitions and axioms even exist is what is earning you the ire you are experiencing.
I'll just start flagging you for trolling then. It's one thing to attempt to have a meaningful discussion and unintentionally provoke ire. Meaningfully doing it by being obtuse and smug... I guess qwerty was spot on with the Randall Monroe quote.
> Meaningfully doing it by being obtuse and smug...
I don't think I was being obtuse. I just expected (in the statistical sense of the term “expectation”) the reaction I got, and decided that it don't mind it.
Why do you not mind being poorly understood? The goal of effective communication is to have others understand you. Since you're not trying to communicate effectively, what exactly is it that you think you are doing?
What I said I didn't mind is the “ire you are experiencing”. It somewhat saddens me that programmers, supposedly logical thinkers, can't see the distinction between a value and an object.
> Since you're not trying to communicate effectively, what exactly is it that you think you are doing?
I'm pointing to the distinction between values and objects pretty clearly:
(0) Objects exist in memory. Values exist in the language's semantics, not in computer memory, but representations of values exist in computer memory. Furthermore, objects exist in memory exactly once, but a value may be represented in memory any number of times.
(1) It doesn't make sense to distinguish between representations of the same value. If a program treats two memory blobs differently, their contents represent different values, period. (The converse is not true, of course.)
(2) The language implementation has absolute freedom to represent values as it wishes, as long as (1) isn't violated.
But this isn't the first time I've said all of this in this thread.
>It somewhat saddens me that programmers, supposedly logical thinkers, can't see the distinction between a value and an object.
We can see the distinction, we just don't use the same terminology you use. We use standard terminology by which what you call an object is a value. Your definition of the terms only shows up in an obscure part of FP, which is still a bit obscure in itself. Use alternate terminology, or explain yourself the first time you use it in a thread - otherwise, we'll all be confused.
I've tried to point this out to you at least three times, and I'm losing my patience.
This brings to mind another Munroe quote: "You're like the religious zealots who are burdened by their superiority with the sad duty of decrying the obvious moral decay of each new generation. And you're just as wrong."
> We can see the distinction, we just don't use the same terminology you use.
No, most of the people I've talked to here clearly couldn't see the distinction between a value and its representation. (FWIW, I'm not fully convinced you can see it either.) They're not used to thinking about values without thinking about how they're represented. They're abstraction-challenged.
> We use standard terminology by which what you call an object is a value.
That's not consistent with some of the things other people have said here. But let's ignore that. What do you call what I call a value? Not that I'm a nominalist, but in practice, I've seen that people don't understand concepts they don't have a name for. (Though I probably have the causality backwards. It would be more accurate to say that, as soon as people understand a new concept, they rush to give it a new name.)
> Your definition of the terms only shows up in an obscure part of FP, which is still a bit obscure in itself.
It's not obscure. It's in the operational semantics of any call-by-value language, which for practical purposes means any language other than Haskell.
> I've tried to point this out to you at least three times, and I'm losing my patience.
Well, it's not like you have to deal with me if you don't want to. You do so out of your own volition. shrug
There's a differance between being abstraction challenged and wishing to understand the abstraction.
We don't have a name for what you call values, as they're either irrelevant, or nonexistant in most contexts, and barely mentioned. However, we can't call them values, as that name is taken. Most CBV languages call them atoms, but that doesn't fit because they aren't necessarily atomic.
Let's try... Symbolic value? It seems to work: a given symbolic value represents all other equivalent symbolic values, and it's value that behaves like the symbol type in most languages. So that works unless it's already taken.
The point is, your definition of value needs a name that doesn't collide with the names of similar concepts and ideas. It doesn't really matter what it is. Unfortunately, this is one name clash that gensym can't handle for us. :-)
> We don't have a name for what you call values, as they're either irrelevant, or nonexistant in most contexts, and barely mentioned.
They do exist. Python has va... errr... the-thing-for-which-we-don't-yet-have-a-name: small enough numbers, special constants and object references. And they are relevant, because these are the things that you can bind to variables, pass to and return from functions, etc. If you think they are irrelevant, you don't understand them well.
> However, we can't call them values, as that name is taken.
I won't quibble about names.
> Most CBV languages call them atoms,
C is call-by-value. No atoms. Java is call-by-value. No atoms. ML is call-by-value language. No atoms. Maybe by “call-by-value”, you mean “inspired by Common Lisp”? That's not what call-by-value means, though.
> but that doesn't fit because they aren't necessarily atomic.
Right. In fact, the whole point is to use compound ones whenever we can!
> Let's try... Symbolic value? It seems to work: a given symbolic value represents all other equivalent symbolic values, and it's value that behaves like the symbol type in most languages. So that works unless it's already taken.
A symbol is supposed to represent something else, but a va... errr... the-thing-for-which-we-don't-yet-have-a-name doesn't represent anything else. If anything, what I call representations are the ones representing something else.
I propose “mathematical value”. Not everything you call a value can be plugged into an equation, but mathematical values by definition can.
Why do you reference call-by-value? Call-by-value vs. call-by-reference (and the related value- and reference-type semantics) is entirely about the in-memory representation of parameters, and you have been very adamant that your definition of value does not depend on in-memory semantics.
...And that should have taught you something: it should have taught you that the language you're using isn't being readily understood, and that you need to either explain it, or change it.
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.
"What we've got here, is a failure to communicate."
Your definition of a "value" seems to be a strictly immutable, functional-oriented definition. Which is fine; that's a valid definition and there's nothing wrong with it. The issues come from the fact that you seem to refuse to accept that that is one definition of many, and continue to push it without compromise.