Value Existence Proof Three

Continued from ValueExistenceProofTwo, which got TooBigToEdit.

(On values being allegedly immutable)

So the bucket itself is not mutable, we both agree (for practical purposes). Right? But the "contents" of the bucket ARE mutable, as we can put in and take out different content to and from the bucket. Agreed? However, rocks are a problematic analogy. In the physical world, you typically have to remove the existing rocks to put in new rocks. It's not practical to smash the rocks into dust and then rebuild new rocks (unless maybe we are recycling pottery). But with electronic flip-flops, we don't have to remove any existing physical "thing" to put in a new/different physical things. It's more equivalent to switching a gate(s) to change the flow of fluid (or flowing electrons). Signals change the direction or "state" of "fluid gates" to alter the flow to a different path (gulley), as needed. Values (content) are NOT solid "things" in the chips such that your rock analogy is a poor fit. There is nothing clearly equivalent to your rocks in chips. Any such mapping requires indirect and contrived fittings or associations or additional layers of pretend or abstract hardware. (I don't believe common notions about languages to be heavily influenced by hardware, but I'm entertaining your claim to see if it provides some insight into the origins and nature of your rather curious and seemingly alien notions about common beliefs among programmers.)

It's a casual analogy, intended to clarify. It's not meant to be a precise "rock and bucket" model of VonNeumannArchitecture. It's better to skip analogies entirely, and recognise simply that slots (memory addresses or variables) contain values, slots are mutable in that a different value can be stored in a slot, but values are immutable. With this simple model, the distinction between values, variables and types can be easily explained and understood. Without this simple model, it's likely that values, variables and types will continue to be unhelpfully misunderstood as an indistinct muddle, resulting in a poor grasp of programming language semantics which leads to poor programming.

I cannot objectively verify that "values are (or must be) immutable".

It's self-evident, and correct by definition. A "mutable value" isn't a value; it's a variable, by definition. It's a variable because it has a time-varying aspect, which is -- inevitably -- a value.

If that's the case, then values can never exist in existing RAM-based hardware because every bit/slot of RAM is potentially mutable. Mutability is relative. My "values" are not mutable to the app code writer, but are mutable to a model fiddler. Same with your "values": they are mutable to a model fiddler, or at least to a RAM hacker.

Certainly values exist. They're what are stored in every RAM address. Changing a bit replaces a value; it doesn't alter the value itself. I know of no architecture where 3 becomes 4; in every architecture, a slot that holds a 3 now can hold a 4 later.

It does not appear to be "replacement" in terms of physical replacement as typically observed during "replacement" of physical objects, as I already explained. No material can be observed to be removed, for example. It doesn't fit the profile of physical observations of replacement in the everyday world. It again appears as if you are mistaking your personal head model for universal or objective truths. Either that, your notion of what "replace" means in English is far different than mine.

Again, beware of taking illustrative analogies too far and trying to treat them as models. Computational machines are unique, such that analogy inevitably fails because there is nothing else precisely like a computational machine. Whilst the notion of "replacement" is a helpful device to aid casual understanding, it is not precise. In order to be precise, it is necessary to dispense with analogy and accept the pure abstraction: That slots (memory addresses or variables) contain values, slots are mutable in that a different value can be stored in a slot, but values are immutable. This simple model makes it possible to understand values, variables and types without any blurring between them, and at the same time allows us to use those concepts to predict and explain all behaviour in (at least popular imperative) programming languages.

Words like "replace" come from the physical/social world of "common" humanity. That's the usual frame of reference for such words, for good or bad. As as far a non-physical abstraction, that's fine as a situational working term, but your version is not universal nor universally required. And, in terms of the tag model, not helpful for illustrative purposes per my judgement of target audience WetWare. Yes, I know you disagree about the target audience WetWare, so there is no need to rekindle that sub-debate for the 13th time (approx.). And I don't "blur between them" as I define "value" in the model.

Further, it was you who suggested we look at "computer architecture" for examples of explicit "values". Now you seem to be back-tracking. It turns out to be not any more concrete at the hardware level then it was on a language or interpreter level. We are just reinventing the same arguments at a different level of architecture.

Of course it's concrete, at all levels. What does a machine register store? What do you push onto a stack? What do you pop from a stack? What is stored in a memory address? In all cases, the answer is "a value".

Whatever a register or memory address stores is not immutable, whatever we call it. If "value" requires immutability, then it's not what memory addresses directly store: the content of a RAM address is mutable. You can envision a pretend or virtual middle-man object called a "value" that's not mutable, fine, but that's merely a UsefulLie at best (and a distraction at worst), but not a universal objective truth. The content is mutable. Perhaps sub-components of content may modeled as immutable, but such is not the only working model.

Think of it another way: At a given point in time, any variable (or register, or memory address) has a particular state. Whilst a variable may take on various states at various times, a particular state is -- by definition -- immutable. "Changing" state means referencing a different state. The usual term for a possible state of a variable (or register, or memory address) is a "value".

Every change and zero changes can be viewed in such terms, if one so chooses. Sometimes it's helpful to model something that "changes state" as being "swapped out" for a different one, or model it as being mutable. Both can often be made to work, but the real question is whether using such a view is "helpful".

Absolutely it's helpful. It clearly distinguishes values from variables, and makes it possible to recognise a type as a set of values. Treating values as mutable (despite being contrary to any meaningful definition of "value") forces a conflation of values and variables, and blurs the otherwise clear distinction between types, values and variables. Treating values as immutable makes values, variables and types trivially distinct, which simplifies understanding of programming languages. 

   // example choices_382
   IF approximate "type" notions are good enough THEN
     use approximate notions.
   ELSE IF more rigor or x-ray-ability is desired THEN
      IF you find the academic approaches difficult to digest THEN
        try top's tag model, it's based on imperative algorithms and XML,
        which is something you likely use often at work.
      ELSE
        dig in the academic materials or fork over 70k for more school.
      END IF
   END IF
We could model human aging as swapping out each person with a different version of the person every morning, and say that people are not mutable, but rather being replaced by older-styled variations. But, is that thought model actually useful? That's the real question. Yes, we can view memory addresses in a similar way, but in many cases it serves no purpose or provides no net improvements to a model in terms of the model's intended purpose.

Again, by introducing "human aging" as an analogy, you're trying to stretch analogies to fit where analogies will not fit. Analogies are ultimately unhelpful, because the only appropriate analogy for a computational machine is another computational machine. Computational machines are unique; no non-computational analogy will fully fit.

It was not an analogy, it was an application of the your "state swap" view (for lack of a better term) to demonstrate how the mutability view and the state-swap view are generally interchangeable. The benefits or weakness of each depend on circumstances and WetWare of the model user and neither are absolutely right or absolutely wrong (except maybe if we gained a God View of the guts of the universe). Maybe the universe really is generating a different instance of everything per "click" of time. We can't rule it out. (That idea is not any weirder than some other quantum theory related hypotheses, such as the Many Worlds hypothesis). In the everyday world, we generally only consider state-swap happening if the "prior version" can be seen and typically has to be moved out of the way or discarded/recycled. But in virtual worlds, we don't need this step such that one can use either model interchangeability. To insist that either one is "the only right view" is silly. The benefits of either is more about weighing model description/grokking/implementation tradeoffs, NOT absolute truths. -t

I don't follow your pseudo-philosophical ruminations, which still seem to be attempting analogies. It would help to think solely in terms of computation and computational machines, not things which are neither.

It's the same issue with chips: both the state-swap model and mutation model can fit observations. The actual physical model of such chips/transistors is "flow redirection" as already discussed such that both are merely UsefulLies. We don't want to model electron flow systems at a higher level, and it's not "natural" to most human thinking. Perhaps we should study electro-mechanical computers so we don't have to delve into how transistors work. As I roughly understand them, they generally had the equivalent of a toggle switch for each "bit". A current on the left side of the switch will either switch the toggle "on", or leave it "on" if it's already there, and the current on the right side will either switch the toggle "off" or leave it off if it's already there. To me, this process is clearly NOT "replacing", and therefore does not fit your description/view of immutability. -t

A physical model that matches what you describe would be more like the old-fashioned gas-station price boards: One has a special long stick to grab the old digit card, take it down, and replace it with a new (more relevant) digit card. But that's not how computer hardware typically does it.

It doesn't matter how computer hardware or gas-station price boards do anything. Think solely in terms of computation and computational machines, not electronics or analogies.

I'm not following. Please clarify.

You're still trying to use analogies. Try not using analogies.

I'll try to cut down, but please explain exactly what a "computational machine" is.

A programmable computer that can run programs.

That's what we went over above when we looked at RAM and "replace" etc. There is no physically observable "replace" happening. You seem to be projecting your personal mental models into physical things. The mutate model is a better model of what's actually observable. If you disagree, so be it. Let's LetTheReaderDecide and move on.

There is a physically observable "replace" of values happening in computers, because we can't observe any transition from one value to another. There's no point at which we can observe a memory address partly containing the old 3 and partly containing the new 4. It's either 3, or it's 4.

And the gas station analogy was meant to show what your version of "value replace" would actually look like. It's NOT intended as an analogy, but a proof of concept for your viewpoint (as the word "replace" is typically used in the real world). Such could be implemented/automated in computational hardware. I provided it to contrast with existing hardware and to demonstrate how most would interpret your wording in terms of hardware implementation. In fact, punched cards were like that. They were rarely directly changed, but rather the old one discarded and a new copy made with the changes in place. -t

Hardware implementation is irrelevant. This still appears to be an attempt to appeal to analogy, where analogies are ultimately inappropriate.

It's NOT an analogy, as explained. I thought you said hardware was relevant; you appear to flip-flopping again. Confusion abounds. If we are talking only about abstract (virtual) views, then abstract view A is not more relevant than abstract view B as long as they both produce the same results (IoProfile). Your implication that started this hardware discussion is/was/? that "common notions" are shaped by computing machinery. -t

Ironic that you are flip-flopping about RAM flip-flops. -t

I suggested looking at computer architecture to recognise the basis of immutable values and mutable variables, but you appear to have misunderstood the relevance.

Apparently so. You are not describing your position well. Observation of RAM does not provide clear evidence of "immutable values". I don't know where this clear evidence is.

Understanding VonNeumannArchitecture and the simple mathematics upon which it is based does, however, provide clear evidence of immutable values. Note that there is no arithmetic that mutates a 3 into a 4. We do not, for example, define simple numerical addition as mutating any operands of the '+' operator; instead, we define it as producing a new value as a result.

PageAnchor English-Universe

You seem to interpret English different than most other people. "Replace" means something very different to YOU than to me. I don't know how to remedy that. It's like talking to an alien from another universe with different physics. In MY universe, "replace" almost always leaves detectable remnants/waste such that I expect detectable remnants if "replace" is happening. If there are no remnants, it's indistinguishable from a "message" to change state, such that I would call such a "message" in my universe. In your universe, "replace" ODDLY has no such side-effect. If replace means something completely different in cyber-space than the physical world, then that's news to me and I need a cyber-space dictionary that's been cleansed of the everyday physics and processes that originally shaped English. Such a dictionary would give clear cyberland definitions of common words like, "has", "is", "contains", "change", "replace", etc. (Granted, a "message" can leave behind debris in the physical world, but unlike "replace", the debris resembles the message device, not the "fixed" item containing the content. If the message and the content item are of the same construction, then "change" versus "replace" are indistinguishable anyhow, barring some marking technique, making them interchangeable viewpoints.)

Your difficulty with language reminds me of bookkeeping students who get completely hung up on what "debit" and "credit" mean, to the point of being unable to grasp simple concepts because they persist (and perhaps insist) on tripping over what the word implies to them, rather than what it actually means. Note that the term "replace" is not essential; it's more important to recognise that variables are mutable and values are immutable. Whether we call it "replace" or "change" or <whatever> matters not, as long as we understand what it means.

MY difficulty with language? I propose YOU have the difficulty in that you mistake your personal interpretation as a universal truth. And my "values" are not more or less immutable than yours. I'm not entirely sure what your complaint is; you seem to flip flop. Per naming actually used in my model, my "values" don't demonstratively violate such. You appear to be quibbling about some extremely minor and obtuse philosophical nit. As far as your accounting anecdote, I don't know those students or their issues and so cannot comment. Generally as long as one can guess how future accounting coworkers and auditors are likely to label something, that's good enough to get work done. It doesn't matter if they are "wrong" as long as you can predict their classification and match it. It's a form of IoProfile per matching the "output" of people and auditors instead of interpreters. You only have to match them, not philosophically agree with them to get work done and paid. One of the jobs of legal experts is to predict how a judge or jury may interpret a given law. Whether the judge or jury is "right" is moot: one is paid to predict them, not "fix" them. Accountants have similar responsibilities when classifying transactions. If they have a disagreement with how something "should" be classified, they can take it to an accounting association or a professional discussion forum. But don't gum up your current employer's operations by forcing your classification into the existing system/environment when it will create a likely flag (mismatch) with auditors etc.

You appear to have misunderstood my example. The problem with the accounting students who get hung up on what "debit" and "credit" mean is that it inhibits their understanding of bookkeeping and accounting. All that "debit" and "credit" really mean are the left and right hand columns, respectively, of a bookkeeping ledger. Those who try to infer greater meaning to "debit" and "credit" -- such as whether money is being added or subtracted or loaned or deposited or going in or out or whatever -- inevitably wind up confused. Similarly, getting hung up on whether "replace" or "change" or <whatever> is the best term to represent what happens to variables will inhibit understanding rather than helping it.

I'm just trying to analyze your claims, as given in English by you. Careful dissection of the meanings of YOUR words is the only way I know how to analyze your claims. That's all I have to go on with your claims: your words. It's your English glowing there on my screen, nothing else. If terms like "replace" mean something different in "computer science" (cough), then please give the sources and glossaries or usage statistics that back your interpretation of such words. Otherwise, I'll analyze such words based on "everyday life". -t

Rest of reply moved to LearnPatternsIfLogicNotFound

Look at str_replace() in PHP or string.replace() in Python. In both cases, a given substring is replaced with another. Notably, neither "leaves detectable remnants/waste" (your words) of the string that was to be replaced. Such use of "replace", in ComputerScience and SoftwareEngineering, is commonplace.

True, but the word choice may be because nobody found a better name, or it's good enough. Many systems call it "substitute", which is more technically accurate in my opinion, but longer. Further, that usage does NOT forbid the existence of debris, for the debris could be dumped in an internal garbage can (GC?) without the function user having to be concerned with who empties it. English usage is not rigorous or consistent when applied to the technical world. And this allows two or more approaches to be "right" even though it may create a potential inconsistency. As I mentioned before, "change the value" is frequent in form and spreadsheet discussions, implying values are mutable. For these reasons, one shouldn't put too much stock in English, especially in arguing that there is OneTruePath. Because you are arguing for OneTruePath in type modelling, you have a higher burden of evidence than I do. I only claim my model does not contradict a significant portion of common notions/usage, I don't claim it matches the OneTruePath of type models or the OneTruePath of English or that there even is OneTruePath of type models (if we exclude implementation, which is geared for machines, not human grokking.)

I'm not arguing for OneTruePath, only against your model which is flawed.

No, it's not. You have not shown that it violates any clear-cut rule other than rules you made up in year head, but mistake for external universal truths. RAM is not immutable by most accounts, thus no "value" (cell content) in any fucking interpreter is 100% "immutable" in an objective and measurable way using physical tools and photons. QED. The RAM model you use in your head is an arbitrary model with arbitrary rules (or at least unnecessary rules).

I have made no claims of "external universal truths", only that your model is flawed because it conflates immutable values and mutable variables and explicitly associates types with variables. Your expressions evaluate to a mutable thing -- that is both practically wrong (why would we mutate the result of an expression?), and theoretically wrong per mathematics (values are immutable by definition). Explicitly associating types with variables is wrong per conventional descriptions of dynamically-typed languages.

"Immutability" is relative, like I already described. Anything in RAM is potentially mutable. I only need to things to be immutable per matching the reference interpreter's level regarding immutability to be "correct". The intermediate internal parts are NOT changeable via the input source code; and thus I satisfy the requirements. Any fussing outside of that is bitching over personal internal design preference. SafetyGoldPlating the internal parts from internal gut fiddlers is a PersonalChoiceElevatedToMoralImperative. As a training system, I want the guts to be fiddle-able. LearningByBreakingStuff? is a valid way to learn. Toddlers do it all the time. Ideally they would be photographic-minded geniuses like little Sheldons and we could just plop them in the library and they'd absorb everything without breaking anything. But most humans are not like that.

Re: "values are immutable by definition" - In that case, then common speech and RAM physics kicks the definition in the nuts. But you over-apply it in that mutability is generally considered relative to something. Further, the things labelled "values" in my model are not any more or less immutable than your "value", based on the info you've given. If you stated in your model, "they must be implemented using a write-only structure (create only)", then I might give your model credit for making them immutable from the interpreter source-side side, but that STILL does not prove "common usage/semantics". That would only be a feature specific to your model.

What you happen to call "values" in your model is irrelevant. What are the values in your model (again, whatever you call them matters not) -- the constructs returned by function invocations and which are the result of expression evaluation -- are mutable. That is mathematically incorrect.

Re: "Explicitly associating types with variables is wrong per conventional descriptions of dynamically-typed languages." -- Prove it using statistical sampling of written descriptions of languages. (One language does not prove it. There are different ways to build/model variables.)

See http://perldoc.perl.org/perlintro.html#Perl-variable-types -- "Perl has three main variable types: scalars, arrays, and hashes." -- given we've been talking primarily about scalars, and given that "scalar" is essentially a catch-all for any scalar type, it implies (and the examples illustrate) that any scalar value can be assigned to any Perl scalar variable at any time. Hence, it is (within its scalar, array or hash domain) untyped.

See http://en.wikibooks.org/wiki/Python_Programming/Data_types -- "It is important to understand that variables in Python are really just references to objects in memory. If you assign an object to a variable [...] all you really do is make this variable [...] point to the object [...] which is kept somewhere in memory, as a convenient way of accessing it." -- i.e., a variable is a named pointer; no indication of a 'type' property associated with it. 

         class Value {
              private Bitstring representation;
              private Type type;
              public Value(BitString representation, Type type) {
                this.representation = representation;
                this.type = type;
              }
              public BitString getRepresentation() {return representation;}
              public Type getType() {return type;}
         }


         // Variables are a hashmap defining mutable relationships between names and values.
         HashMap<String, Value> variables = new HashMap<String, Value>();
.

See DynamicTyping -- "Another term that is sometimes used is 'value typed' opposed to 'variable or reference typed'." 

                 <variable name="foo">
                     <object>
                          <value ...>
                     </object>
                 </variable>
. See http://www.php.net/manual/en/language.variables.basics.php -- "By default, variables are always assigned by value. That is to say, when you assign an expression to a variable, the entire value of the original expression is copied into the destination variable. This means, for instance, that after assigning one variable's value to another, changing one of those variables will have no effect on the other." -- No evidence of a 'type' attribute associated with variables.

See http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-c-and-cpp/ -- "Objects are strongly typed (and variable names themselves have no type at all)." -- Quite explicit, here.

"Name"? Variable "names" don't have (explicit) types either in my model. (That's bad writing, regardless. Fire the bastard.)

It's bad writing, but the meaning is clear.

I disagree. You make it "clear" in your mind by seeing it only how you want to see it. You read English with heavy bias. Names "having" types is an odd concept, or odd wording. What would be an example of such? Like dollar signs in BASIC classic?

Note that the vast majority of such manuals do not define "value" and use it in kind of a cavalier way, sprinkled in here and there with minimal if any explanation.

The vast majority of manuals do not define "value" because the vast majority of manuals assume the reader is a programmer who knows what values are.

In a rough notion/feeling sense, sure.

No, in a ComputerScience sense.

No, ComputerScience does NOT formally define "value". And I thought you were addressing "commonly understood semantics", not the ivory tower sense. Make up your mind which audience you intend to satisfy with your model.

Sure it does, or it adopts the notion from mathematics. Look in any introductory ComputerScience text, which every professional programmer should have read.

Sorry, I don't see it. And programming does not have to borrow everything from math. It can pick and choose what to borrow.

Whether you see it or not, it's there.

One of us is hallucinating.

If it was both of us, how would we know?

Everybody else would ignore us.

You could be hallucinating that everyone is ignoring us.

Odd, what happened to MarkJanssen's comments? -t

Oops, he edited whilst I was editing so I pushed my edits, and I was going to put his back in but I forgot. I'll do it now. Thanks for catching that.

Computer software is all about making sense of a whole lot of states and logical gates. The rest is all sugar. -- ChaunceyGardiner

Perhaps. Another view is that a whole lot of states and logical gates are just some electro-mechanical sugar we use to speed up the execution of computer software.

CategoryMetaDiscussion

JanuaryFourteen

EditText of this page (last edited January 28, 2014) or FindPage with title or text search