This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
To-do list for Value (computer science):
|
Esap:
Regarding your most recent edit:
I was about to edit this page when I noticed your most recent edit. It appears you and I have very different notions of what "values" (in CS) are. In the interest of reaching concensus I would like to try to:
To this end, I would like to ask you a few questions:
-- Eelis 23:07, 2005 May 26 (UTC)
The notions of value and object are conceptually more separate than the article implies, especially given the heavy OOP focus of the [[object(Computer Science)|object] article. More importantly, this article is misleading wrt functions as values -- the prevalence of functional programs should merit at least a mention of functions-as-values, especially in lambda-calculus-based languages like [[LISP programming language|LISP] and [[ML programming language|ML].
I think that the article ought to focus on values as the abstract meaning of data (as in "the value 3") and/or as data for which no "simpler" form exists (as in "the value of 2 + 2 is 4", or "the value of this piece of code is the cosine function"). In that regard, an object (in the OOP sense) is merely a special sort of value -- one that has internal state or a virtual method table, and is capable of self-mutation through contained procedures (methods). An object in the more generic sense is also a value, as both are "things having semantic meaning".
The notion of values-as-things-stored may be useful, but (as far as I can tell at this point) only for differentiation between an algorithm and the result of running an algorithm. The notion of values-as-bits is not useful, as values could be represented as
qubits (which are not bits) and non-values (such as unsimplified or un-[Evaluation|evaluated] code) can be represented as bits. Perhaps the best way to describe values is simply as fully-simplified
expressions (I'll try to add such a comparison
real soon now).
The fact that the existing article mentions things like "inheritance" and "control flow" as non-values seems a strong potential point of confusion to the reader -- it draws emphasis away from values-as-obtianed-data and pollutes an otherwise instructive (if somewhat inaccurate) list of "things which are not values" (such as labels) with "concopts which are not 'value'".
I would go ahead and make all these edits, but it seems there are already some conflicting viewpoints. As I'm proposing some pretty radical changes I didn't want to piss anybody off, so I'm gonna wait a bit and see if anyone cares.
bmills 8/24/05
I believe one of the primary distinguishing factors between a value and an object is that objects are always stored to some specific location, whereas a value does not have any connection to location to which it is stored in. This distinction is often muddied when referential transparency is used (when storage locations are not important), and values are all you have.
esap 07:33, August 27, 2005 (UTC)
In this phrase (near the top of the article):
such as the location in which the bits produced by the expression are stored in,
the word "in
" appears twice. I was about to just get rid of one of them ("be bold"),
but I don't really care much, which one we keep. Any comments, before I just pick one?
Mike Schwartz (
talk)
00:36, 23 May 2008 (UTC)
"L-values are values that have addresses, meaning they are variables or dereferenced references to a certain memory location."
AFAIK in C, you can (theoretically) make a variable of the "register
" storage class like this:
register int foo;
foo = 42;
foo
is an lvalue but it may or may not have a memory address, depending on the compiler used. Even if it has one, trying to retrieve its address by &foo
gives a compile-time error.
So how do we address this issue in the article?
"R-value is either R-value or non-L-value — a term only used to distinguish from L-value."
This kind of recursion always makes the concept unnecessarily difficult to understand. Based on my understanding, it simply says that "an R-value means a non-L-value." Am I right?
Frigoris ( talk) 17:16, 22 January 2009 (UTC)
As defined in the lead, a value is (an interpretation of) something inside the computer at run time, not something that could occur in a program text. Therefore the statement that it is the normal form of an expression makes no sense. Indeed some values cannot be denoted by an atomic expression (in most programming languages "-1" remains an operator applied to a positive number), or possibly not even by any expression at all (a language might for instance not have any expressions for array values) and conversely different atomic expressions might have the same value (using decimal, octal and hexadecimal notation for instance). So the statement about normal forms should be removed. Marc van Leeuwen ( talk) 08:03, 22 October 2010 (UTC)
Yes. I am doing this now. LiberalArtist ( talk) 07:09, 4 October 2017 (UTC)
Instead of "Another example is the C expression (4 + 9)", it may be better to write "the expression (a + b)", since "(4 + 9)" boils down to just another immediate, which was already explained in the previous paragraph. — Preceding unsigned comment added by 92.192.94.225 ( talk) 13:48, 25 October 2011 (UTC)
The notion of "value" is tricky, so I'm not surprised that this article has several problems:
E.g. X-value (and lots more) is a missing page. I believe C still has only l- and r-value, and many other languages. Is this too much trivia here (what to say, only that there are more and add this link)? Are these new ones only in (recent) C++? comp.arch ( talk) 11:34, 24 October 2017 (UTC)
Not entity, but expression. Checkout the in C++ draft. AXONOV (talk) ⚑ 12:49, 6 August 2022 (UTC)
This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
To-do list for Value (computer science):
|
Esap:
Regarding your most recent edit:
I was about to edit this page when I noticed your most recent edit. It appears you and I have very different notions of what "values" (in CS) are. In the interest of reaching concensus I would like to try to:
To this end, I would like to ask you a few questions:
-- Eelis 23:07, 2005 May 26 (UTC)
The notions of value and object are conceptually more separate than the article implies, especially given the heavy OOP focus of the [[object(Computer Science)|object] article. More importantly, this article is misleading wrt functions as values -- the prevalence of functional programs should merit at least a mention of functions-as-values, especially in lambda-calculus-based languages like [[LISP programming language|LISP] and [[ML programming language|ML].
I think that the article ought to focus on values as the abstract meaning of data (as in "the value 3") and/or as data for which no "simpler" form exists (as in "the value of 2 + 2 is 4", or "the value of this piece of code is the cosine function"). In that regard, an object (in the OOP sense) is merely a special sort of value -- one that has internal state or a virtual method table, and is capable of self-mutation through contained procedures (methods). An object in the more generic sense is also a value, as both are "things having semantic meaning".
The notion of values-as-things-stored may be useful, but (as far as I can tell at this point) only for differentiation between an algorithm and the result of running an algorithm. The notion of values-as-bits is not useful, as values could be represented as
qubits (which are not bits) and non-values (such as unsimplified or un-[Evaluation|evaluated] code) can be represented as bits. Perhaps the best way to describe values is simply as fully-simplified
expressions (I'll try to add such a comparison
real soon now).
The fact that the existing article mentions things like "inheritance" and "control flow" as non-values seems a strong potential point of confusion to the reader -- it draws emphasis away from values-as-obtianed-data and pollutes an otherwise instructive (if somewhat inaccurate) list of "things which are not values" (such as labels) with "concopts which are not 'value'".
I would go ahead and make all these edits, but it seems there are already some conflicting viewpoints. As I'm proposing some pretty radical changes I didn't want to piss anybody off, so I'm gonna wait a bit and see if anyone cares.
bmills 8/24/05
I believe one of the primary distinguishing factors between a value and an object is that objects are always stored to some specific location, whereas a value does not have any connection to location to which it is stored in. This distinction is often muddied when referential transparency is used (when storage locations are not important), and values are all you have.
esap 07:33, August 27, 2005 (UTC)
In this phrase (near the top of the article):
such as the location in which the bits produced by the expression are stored in,
the word "in
" appears twice. I was about to just get rid of one of them ("be bold"),
but I don't really care much, which one we keep. Any comments, before I just pick one?
Mike Schwartz (
talk)
00:36, 23 May 2008 (UTC)
"L-values are values that have addresses, meaning they are variables or dereferenced references to a certain memory location."
AFAIK in C, you can (theoretically) make a variable of the "register
" storage class like this:
register int foo;
foo = 42;
foo
is an lvalue but it may or may not have a memory address, depending on the compiler used. Even if it has one, trying to retrieve its address by &foo
gives a compile-time error.
So how do we address this issue in the article?
"R-value is either R-value or non-L-value — a term only used to distinguish from L-value."
This kind of recursion always makes the concept unnecessarily difficult to understand. Based on my understanding, it simply says that "an R-value means a non-L-value." Am I right?
Frigoris ( talk) 17:16, 22 January 2009 (UTC)
As defined in the lead, a value is (an interpretation of) something inside the computer at run time, not something that could occur in a program text. Therefore the statement that it is the normal form of an expression makes no sense. Indeed some values cannot be denoted by an atomic expression (in most programming languages "-1" remains an operator applied to a positive number), or possibly not even by any expression at all (a language might for instance not have any expressions for array values) and conversely different atomic expressions might have the same value (using decimal, octal and hexadecimal notation for instance). So the statement about normal forms should be removed. Marc van Leeuwen ( talk) 08:03, 22 October 2010 (UTC)
Yes. I am doing this now. LiberalArtist ( talk) 07:09, 4 October 2017 (UTC)
Instead of "Another example is the C expression (4 + 9)", it may be better to write "the expression (a + b)", since "(4 + 9)" boils down to just another immediate, which was already explained in the previous paragraph. — Preceding unsigned comment added by 92.192.94.225 ( talk) 13:48, 25 October 2011 (UTC)
The notion of "value" is tricky, so I'm not surprised that this article has several problems:
E.g. X-value (and lots more) is a missing page. I believe C still has only l- and r-value, and many other languages. Is this too much trivia here (what to say, only that there are more and add this link)? Are these new ones only in (recent) C++? comp.arch ( talk) 11:34, 24 October 2017 (UTC)
Not entity, but expression. Checkout the in C++ draft. AXONOV (talk) ⚑ 12:49, 6 August 2022 (UTC)