Talk:Value (computer science)

Untitled

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:

• understand your point of view; and
• find out what you feel is inaccurate about my point of view.

To this end, I would like to ask you a few questions:

1. How do you feel about the first few paragraphs of the Object (computer science) article (which were mostly written by me)? Note in particular the emphasis on contiguousness (and motivations for that emphasis).

I didn't really understand the paragraphs talking about contiguousness. Is that paragraph trying to describe encapsulation in objects? Otherwise it's clear and I agree it's useful to distinguish between "object as an encapsulated region of storage" and "object as a conceptual point-like thing" (then there is also a category theory definition that could be thought of as an abstraction of a datatype). I think the levels of detail are discrete, because bits are indivisible. esap 16:22, May 28, 2005 (UTC)

1. Do you agree that your edit was very C-centric in its examples and terms used?

Yes, I tried to maintain the overall tone of the whole article, which, to me, seems very C-centric anyway. Maybe it should change, but my edit was not intended to change that. esap 16:22, May 28, 2005 (UTC)

1. How would you feel about the following primary definition text (which I was about to commit):

A value is a semantic interpretation of the contents of an object. The value of an object depends on how one chooses to interpret its contents. Usually objects are associated (either explicitly or implicitly) with data types that determine the way the data contained in the object is to be interpreted. In this regard, data types serve as a mapping from otherwise meaningless sequences of bits stored in objects to some conceptual set of values.

I would define 'value' without reference to 'object', because my understanding is that 'value' is more primitive concept than 'object'. Say, "a piece of data is a value when the the whole data is interpreted and handled as a single indivisible entity". I don't agree with your definition of a data type. I would consider a data type as an abstraction of a set of values of the same type. The abstraction part is because in a data type, each value is considered as a black-box ("point-like") entity, and the data type just defines what values are part of the datatype. Or in other words, a datatype defines what possible values can be referred to by a name that has the given datatype. esap 16:22, May 28, 2005 (UTC)

Multiple objects can hold the same value (assuming they are interpreted the same way). In some representations, even objects with differing bitwise contents can share the same value. Examples include ones' complement which allows two distinct representations of the numerical value 0, and case insensitive strings where "bLa" and "BlA" (in some character encoding) represent the same value.

I agree with this, but this is of course only half of the story. The other half is that the same bits can represent different values in different interpretations of the bits.

-- Eelis 23:07, 2005 May 26 (UTC)

Too OOP-centric

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 collected languages like Java, the location of an object may change during the execution of a progrom. Furthermore, an ML-like language considers a reference (or pointer) to be a value in and of itself. While it doesn't matter where the reference itself is located, it's not immediately clear that storage makes any difference as to whether a particular value is an object or not -- just that value is a semantic notion (and storage is only sometimes semantically meaningful), whereas object is more of a description of the run-time state of the computation. --bmills 02:05, 12 September 2005 (UTC)

I still think merging this to object (computer science) makes sense. Before talking about definitions, we must agree that terms like values or objects are used very ambiguously. I know we can make distinction but I don't think many are aware of it, and too often people confuse values and objects. -- Taku 11:35, August 27, 2005 (UTC)

It seems more appropriate to keep value and object separate, although the object article probably ought to suggest reading the value article for comparison. It does make sense to merge value (programming) into this article, but the object article is pretty much entirely confined to Object-oriented programming, whereas this article should not be. --bmills 02:05, 12 September 2005 (UTC)

minor nit-pick: ("in" occurs twice, here)

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)

lvalue and rvalue

• From the article, by the time of writing this:

"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?

• Another problem is with the sentence

"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)

The lvalue-has-an-address is meant in another sense. You can apply "&" to non-lvalues in C (function designators) and you can not apply & to some lvalues. Register variables actually have a location. Their address is located at alternative areas (registers), which is the reason their address can't be taken by &. It would need other means of addresses, and would make "int*" need now two value representations: to contain an address of a register variable (like, "eax"), *or* of a non-register variable (like 0x00ff0ff).

Addresses together with lvalues rather mean "locations". that's why lvalues are sometimes called locator-value. 84.174.226.78 (talk) 14:40, 29 April 2009 (UTC)

value is a run-time notion, not the normal form of an expression

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)

Assignment: l-values and r-values

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)

Basic issues

The notion of "value" is tricky, so I'm not surprised that this article has several problems:

• "a value is an expression which cannot be evaluated any further (a normal form)" — in what sense is "evaluated" meant here? Clearly in Lisp, say, the s-expression (list 1 2) is a value, just as the result of evaluating that s-expression, namely (1 2). As for normal forms, plenty of rewriting systems support loops.
• "L-values have storage addresses that are programmatically accessible to the running program..." — this is certainly wrong in general, though true in C. In Algol 60, call-by-name arguments can function as l-values, without Algol 60 supporting an "address-of" operator. I have separated out the generic discussion on R-values from the C-specific part. --Macrakis (talk) 14:18, 1 August 2016 (UTC)

C++ has more value types now..

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)

Entity

Not entity, but expression. Checkout the in C++ draft. AXONOV (talk) ⚑ 12:49, 6 August 2022 (UTC)