''Continued from ValueExistenceProof, which is getting TooBigToEdit''

Re: "contradicts typical understanding of dynamically-typed languages" -- So you claim. -t

{It's true. Why are DynamicallyTyped languages sometimes described as "value typed"?}

I've rarely heard that term. There are a lot of pet terms related to types and values floating around out there. It's a poorly policed vocabulary district. -t

{No one "polices" vocabulary; it is organic.  If usage appears, like "value typed", it's probably a reflection of typical understanding.}

By that measure, if it's uncommon, then it reflects uncommon understanding. You fell on your own sword here.

{Not at all.  I offer "value typed" only as an additional point of evidence.

You have not associated it with high frequency of usage. (See PageAnchor Ratio_01.) If it's low frequency, then it's not of concern to typical developers. I've also given point evidence, such as it being used interchangeably with "literal".

{I never claimed "high frequency", nor would I.  How high is "high"?  How low is "low"?  I'm fully aware that "value" is used as a synonym for "literal", but as I've explained elsewhere, that's entirely reasonable if not entirely precise.  Literals always denote values.}

In the head.

{Yes, and in programming language semantics and the interpreters and compilers that implement them.}

But it's not necessarily one-to-one. Bob can turn his head model A into implementation X. Fred can study X, and create an ALTERNATIVE head model B that mirrors implementation X. Both A and B can model the behavior (I/O) of device X.

{I've no doubt different semantics are possible for the same syntax, but how do you know models A and B are correct?  For example, "a = foo() + 4" can mean "invoke function foo and add its return value to four, and store the result in variable 'a'", but it can also mean "store the expression 'foo() + 4' in variable 'a'".  Will they both produce the same results if we assume writeln(p) always evaluates any expression it is passed, including an expression stored in variable p?}

Experience and testing. And in many cases people's head models are probably less than 100% perfect.

{"Experience and testing" are far less reliable than logical deduction.}

We've had this argument already in ValueExistenceProof; I'm not going to repeat it here.

{Fair enough.  We'll deal with it there.}
----

{Why do DynamicallyTyped languages lack type declarations on variables?}

Because if a literal contains type info, then it's usually redundant. Dynamic languages tend to value brevity compared to static ones, which value explicitness.

{I assume you mean "variable", instead of "literal"?  There was no mention of literals.  DynamicallyTyped languages lack type declarations on variables because DynamicallyTyped languages can be assigned any value of any type at any time.  Therefore, there is no explicit need to associate a manifest type with a variable.  As it turns out, there's no need to associate a type with a variable -- in a DynamicallyTyped language -- at all.}

I'm mirroring existing languages as they are, and their behavior usually does reflect a "type indicator" of some kind. I agree the indicator is a dumb design (except possibly for efficiency), but it's the current style for good or bad. Example of effects in a JavaScript-like language:

   a = 3; write(typeName(a)); write(a + a); // result: Number 6
   b = "3"; write(typeName(b)); write(b + b); // result: String 33
Here above, "b" has something extra or different than "a".

{Actually, no.  Scalar variables in popular DynamicallyTyped languages are undifferentiated.  Variable "a" differs from variable "b" only by the values they contain.  More accurately, it's the 3 has "something extra or different than" "3".  In DynamicallyTyped languages, values have type references.  In Category D1 languages (see TypeSystemCategoriesInImperativeLanguages) the type references are explicit.}

{When a variable is passed as an argument to an operator invocation, the operator only "sees" the value in the variable, not the variable itself.  Outside of assignment, whenever a variable name is used, the interpreter retrieves the value the variable contains.  The value is then passed to the appropriate operator as an argument.  It's the same process whether typeName()'s argument is a variable, a literal, or a function call.  In every case, the interpreter simply evaluates the expression to obtain a value; it doesn't matter whether the expression consists of a variable, a literal, a function call, or a combination of these.  Otherwise, there'd have to be one typeName() implementation for variables, one typeName() implementation for literals, one typeName() implementation for function calls, and one typeName() implementation for expressions consisting of a combination of operators, literals, and variable references.  Obviously, that would be unreasonable, and it's unnecessary.}

* Redundancy in models is a different issue. This is a definition question, not a quality question. 

* {I thought this was a modelling question -- about getting the parts of the model right -- rather than a definition question.  The definition of "variable" has nothing to do with how a variable is modelled.}

* How are you defining "right"? I define it as matching I/O, as already stated. Design issues such as simplicity, redundancy, grokkability, etc. are a different issue(s). Perhaps I misunderstood the original question above. 

* {By "right", I mean "accurately models the real world".  As I've mentioned elsewhere, I'm not sure what "matching I/O" means.  Output and user input can be anything, and an infinite number of programs can take the same user input and produce the same output, so I'm not sure that's meaningful.  If you treat program source code as input, then you must mean the program semantics are meaningful, because an infinite number of semantically-invalid programs won't even run, let alone generate output.}

* Data-Input + Source-Code -> Process -> Output. ANY "Process" that can transform the first two into Output that matches the target language (interpreter) for the same two inputs is considered "correct" in my book. And please, not the "real world" debate again.

* {The problem is the above can admit an infinite number of programs that generate the same Output given different Source-Code.}

* No, I consider source code as "input". See the "+"? Perhaps I am misinterpreting your scope. It's true that for any given INSTANCE of output there are infinite number of programs that could generate it, but not the same "Process" for ALL possible given input sets (data and source code).

* {Sorry, I'm not following you.  The same problem appears to hold true.  Your model, as described here, would appear to treat "write(3); write(4)" and "a='3'; b='4'; write(a + b)" as the same.}

* No no no. The data input AND the source code have to match the "actual" language interpreter's result. It's an "and", not an "or". Maybe this will clarify the expected relationship between the model and the actual language (interpreter).

    // Example loopy-72 -- Comparing I/O profiles
    for d = each possible data input file/stream
      for s = each possible source code input file
        x1 = outputFromRun(modelFoo(d, s))  // the target test model
        x2 = outputFromRun(actualLanguage(d, s))
        if (x1 != x2) then 
          write("Model Foo failed to match I/O profile of actual language.")
          stop
        end if
      end for s
    end for d
    write("The I/O Profile of model Foo matches actual language.")
* In this comparison system, it doesn't matter whether the model uses pigtails and rubber bands, as long as it matches the actual language results given the same two kinds of inputs. I'll consider ANY model (such as modelFoo above) "correct" if it doesn't ever generate the "failed" message above for all loop iterations. (A passing model may not be well-suited for WetWare studies, but that's the second stage. Also, it's not possible to actually test all combinations (a full looping), so spot sampling of some kind would be used in practice.)

** {Given that the above is testing to see whether or not modelFoo() == actualLanguage(), aren't you really saying your "model" isn't a model at all -- it has to be a full compiler or interpreter of the language recognised by actualLanguage()?  Otherwise, modelFoo() cannot possibly be equal to actualLanguage().}

** If it was fully implemented. As described, it makes the "user" do most of the parsing etc., and it can be tested with them doing their part. For our purposes, though, testing would be on type-related snippets, not full applications, because that's not what we are interested in here. I don't see that your model is complete either.

* {I see.  The problem with this is that the sets "each possible data input file/stream" and "each possible source code input file" are infinite.  How, in an automated fashion, can you assume that the next iteration of d and s won't result in "Model Foo failed to match"?  Essentially, you've described a brute-force, exhaustive-search proof of your model.  The only way to demonstrate your model is valid, then, is to demonstrate it works with "'''every''' possible data input file/stream" and "'''every''' possible source code input file".  That's not unreasonable for finite enumerable sets, and sometimes it is used as a successful approach -- a few years ago, a similar approach was used to prove a result in game theory using checkers, which required iterating over every possible checkers game -- but I think you'll need an infinite amount of time to demonstrate that your model works for infinite sets.}

* Like I said, we don't need to test every possibility in practice, only representative samples of issues we are interested in. Plus, an alternative for empirical testing of models has not been found. Possibly related material on empirical versus logical deduction is near PageAnchor mucked-381 in ValueExistenceProof.

* {The alternative to empirical testing is logical proof, based on demonstrating that your model's components are isomorphic to those in popular imperative programming languages.}

* And the only way to know it's isomorphic with anything is empirical testing. (Dissecting the interpreter source code in theory may be sufficient, but not in practice.)

* {Perhaps, but that's certainly feasible.  It's even reasonable.  Exhaustive testing as a form of validation, when the sets are infinite, is not.}

* That's just the nature of science: new observations may come along that invalidate existing models, requiring changing or tuning of models. Science is probably never "done" because we cannot make every possible observation, unless perhaps God comes out of the closet.

* {That approach is appropriate to the natural sciences.  It's unnecessary in ComputerScience, because there are no unknowns (in a scientific sense) in compilers and interpreters.}

* Oh really? Technically you may be correct, but it's not practical for a typical programmer to dissect the EXE of the interpreter. QA/testers wouldn't have a job if you statement was true in a practical sense.

* {It isn't necessary for every programmer to dissect every EXE.  All it takes is one programmer -- say, the interpreter's author -- to document it effectively.}

* Which appears to be the hard part.

* {Admittedly, common documentation -- particularly for DynamicallyTyped languages, for some reason -- seems to be rather poorly written.  The PHP manual is a notorious example.  However, that simply makes understanding more work.  That doesn't mean it's incomprehensible.}

* Time to experiment with alternative approaches. Maybe Tag Model is a long-shot to catch on, but sometimes evolution requires a lot of mutations before a big improvement is found.

* {I have no objection to alternative approaches.  I have an objection to a specific model that (for example) uses contradictory or unfamiliar terminology (e.g., "anonymous constant", or "tag" when it would be more helpful to clarify existing terminology), or that confusingly defines variables as having types in DynamicallyTyped languages when one of well-known distinguishing characteristics of DynamicallyTyped languages is that variables do not have types.}

* PageAnchor tradeoff_rant_48

* Like I keep saying, colloquial usage is overloaded such that compromises likely will be needed when building something more rigorous. You also have awkward usage such as "representation". Glass houses. My trade-off choices were not made capriciously, but balanced against each other to minimize the evil. If you want to attack my decisions, you have to focus on the entire stack of features tied to such tradeoffs. It won't do any good to keep repeatedly pointing out that X is awkward without considering how it may make Y and Z awkward if they are tied to how X is done (WaterbedTheory in terms of both complexity and confusion). You dwell on one note on the piano, ignoring the rest of the keyboard. That's really an annoying aspect of your (plural) debate style. Engineering and design is all about balancing trade-offs; there is '''no known magic/free lunch that optimizes everything at the same time'''. You guys keep trying to find or enforce a One True Way master canonical model. It's probably a lost cause, but stubborn personalities don't give up easily. (And I know you disagree with my assessment of the WetWare of the target audience such that there's no need to repeat that issue again either.)

* {Your response appears to be a rant, containing nothing that specifically and logically defends your use of odd terminology, or that defends your use of a peculiar (and contradictory) model of variables.  If it's clear that your previous points haven't been convincing, then an appropriate approach would be to supply evidence, not analogies about musical instruments.}

* I've explained the logic many many times. In summary, it avoids the awkward and vague term "representation", and simplifies (shortens and de-nests) the data structure used '''most often''' by the model users. It's rational to uglify less-often used parts of the model '''in order to''' clean up or simplify the most commonly used parts. I know you disagree with those tradeoffs; there's no need to keep saying that over and over again repeatedly redundantly multiple times repeatedly. If you don't have any '''NEW arguments''' on that, then shut the goddam hell up! I don't know why you keep forgetting the replies and making the SAME COMPLAINTS over and over like an Alzheimer patient reading the same magazine for the 74th time.  That behavior if fucking stupid. You must be doing it just to agitate me, and it's fucking working: I'm fucking bloody agitated!!!!!!!!! I know I DON'T have an OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy to back my assumptions about programmer WetWare (the only way you'd be "convinced"), but NEITHER DO YOU for assumptions about your model's users. '''You are throwing rocks from a glass house''', the AnecdoteImpasse house. My model trade-off decisions are consistent with my stated assumptions about the model users' WetWare, despite not having "convincing" proof of the way their heads work.

* {Again, your response is mainly a rant.  Lacking qualified evidence -- such as a clear and rational exposition of the supposed "tradeoffs" -- your justification for "the logic" of your model constitutes little more than a statement of personal preference.  I reject it categorically, unless you qualify documentation of your model with a statement to the effect that it is based on your personal assumptions, and does not reflect language semantics or real-world interpreter/compiler realities.}

* Your model likewise appears to be only based on "personal preference", due to your probable overexposure of actual interpreter construction, making you biased to a certain model out of personal familiarity comfort. Matching machine implementation is not objectively a better goal than matching human thought patterns because assisting with human mental forecasting does not have to be tied to the implementation of existing interpreters. Nor have you found an objective way to measure "language semantics" so as to objectively fail my model based on such measurements. As it stands, I treat your "semantic" claims as  supernatural claims. '''Matching actual implementation is a fake requirement due to a logic mistake on your part'''. Again, it very much appears as if you are mistaking your personal mental models for universal truths.

* {I'm not claiming any "universal truths".  They belong strictly to mathematics and are only of philosophical concern.  What I claim to be true is that there are semantics common to all popular imperative programming languages.  My evidence is simple:  A statement like "a = foo() + 3 + b;", for example, has common semantics in every popular imperative programming language, despite (slight) variations in syntax.  I'm not matching my "model" to "actual interpreter construction", I'm matching my "model" to actual language semantics.  Do you deny that language semantics exist?  Their existence can be illustrated:  Given a C#/Java/C/C++/etc. statement like "a = foo() + 3 + b;", how would you describe it?  If you describe it as anything other than "a sequence of characters that follows certain rules for arranging the characters" (which is syntax), you're inevitably talking about programming language semantics.  Semantics can be consistently, objectively, and formally described via DenotationalSemantics and HoareLogic.}

** PageAnchor Hoare_Horror

** Again, I don't dispute that ideas exist (in human heads), I only dispute there is any known objective way to compare them or that they are objectively equivalent in all human heads. (See "hate" discussion.) If you use DenotationalSemantics and HoareLogic, can you prove that 1) They represent semantics and not something else, and 2) Your translation is the ONLY possible way the target languages can be represented in them? If there are other ways to represent the same syntax or interpreter behavior in DS and HL, then you've failed to establish uniqueness (canonical-ity). We've already established there are multiple ways to describe such expressions in both English and in code (interpreters), and thus find no uniqueness there. -t 

** {This has nothing to do with ideas, and everything to do with the parts -- the statements and constructs -- of programming languages and the effects they have on the machine.  "Unique" is not equivalent to "canonical"; "canonical" is a synonym for "standard" or "typical", but not "unique" or "only".  It's occasionally used to mean "archetypal", which I suppose could imply uniqueness, but that would be incorrect here.  There may be multiple ways to interpret the semantics of popular imperative programming languages, but aside from your nuanced interpretation, I've not seen any outside of the canonical one.  I have certainly seen varying levels of detail in descriptions of semantics, but none that are incompatible with each other.  E.g., "a = foo() + b;" can be described as "the value resulting from the invocation of function 'foo' is added to the value in variable 'b' and the resulting value is stored in variable 'a'", or "a is 'foo' plus 'b'".  These describe the same semantics, differing only in detail.  Different semantics would be, for example, "rotate geometrical object 'a' about the axis labelled 'foo' by 'b' degrees."}

** Based on your claims, you need to EITHER establish that there's only one possible "semantics" set to describe expression evaluation (and language processing) in the target "Algol" language style, OR show that most developers use a common set of "semantics". The first I'm calling "unique" and the second "canonical".  Trying to describe "semantics" with English does not convey enough precision to say anything definite or comparable. And your expression-to-English versions are biased to your favorite model; as suggested by your preference to use "value". (I've given a non-value version elsewhere). The '''English versions are arbitrary''' for the most part and varied. Expressions can be evaluated in parallel or semi-parallel, for example, and we generally cannot describe that very well in English because English is sequential. The "semantics" does not have to be sequential. There is no Law of the Universe that says that. Most human semantics is probably influenced by how we did it in school, and I'm not sure "semantics" is different from "algorithm". Students learn an algorithm for evaluating expressions, and this algorithm varies per personality and/or school system. (I gave examples already.) Some students can almost do it in their sleep because the steps become well-entrenched in their minds, and more resemble and algorithm than "semantics" from an outside observer. Without a clear X-ray of human brains working, it's difficult to know which of the two terms best apply. 

** {Why do I need to establish EITHER that "there's only one possible 'semantics' set to describe expression evaluation (and language processing) in the target 'Algol' language style, OR show that most developers use a common set of 'semantics'"?}

** PageAnchor commonality_73

** The question at issue is uniqueness or canonical-ness, '''not mere existence''' of "semantics" for such languages. I'll refer to these requirements together as "commonality" for lack of a batter word for now. You need to objectively find a way to measure and present this "commonality", otherwise it's just a claim without evidence.

** {It's self-evident that constructs like "if (p) {} else {}" and "while (p) {}" have the same semantics in all popular imperative programming languages.  That is sufficient to demonstrate commonality.}

** I'm sorry, it's not obvious to me. Perhaps CommonSenseIsAnIllusion is applicable. Every head is different. I might use the same thought processes between similar languages, but that is not a necessity, nor do other humans necessarily use the same thought processes that I do. '''What keeps somebody from using Head Model A for say End-X style block (VB-like) languages and Head Model B for curly-brace-style languages? (PHP)''' Granted, such may be poor reuse of mental models, but that's a "design quality" issue, not an absolute requirement.

** {If it's not obvious that constructs like "if (p) {} else {}" and "while (p) {}" have the same semantics in all popular imperative programming languages, then there should be an example of a popular imperative programming language where "if (p) {} else {}" or "while (p) {}" differs semantically from other popular imperative programming languages.  What is that language, and how do "if (p) {} else {}" or "while (p) {}" differ semantically in that language?}

** Reply moved to SemanticsDiscussion.


* And I have already agreed my model makes NO significant attempt to match actual interpreter implementations and it says so on the page. Nor does it need to for the stated goal of assisting programmers to forecast type-related results. Bringing actual implementation into this discussion is a red herring. De-merits for you. 

* {If you're claiming your model is an arbitrary approach to mapping '''user''' input to '''user''' output, that's fine.  You can use any approach you like.  As soon as you treat programming language source code as input -- and attempt to draw connections between source code and your model -- you inevitably draw comparisons between your approach to semantics (which is precisely what it is) and existing approaches to semantics.  Unfortunately, two fundamental elements of your model's semantics differ from established, documented semantics:  1. Your model of variables in D1 languages possesses an explicit "type" attribute; 2. your model of values in D1 languages does not possess an explicit "type" attribute.  Because this causes inevitable problems representing common constructs like returning results from functions, your resolution (it seems) is to conflate variables and values, resulting in novel constructs like "hidden variables" and "anonymous constants". That appears to offer no benefits -- and only encourages confusion by introducing undefined terms, whilst not clearly distinguishing values from variables -- with the '''only''' apparent consistent justification being that it "avoids nesting", as if the "nesting" implied by the universally-familiar notion that "a variable contains a value" is somehow difficult to grasp.}

* You have not clearly established the existence of a canonical way of representing variables and values in programmer's minds. (I'm not talking about interpreter writers or experts. They are a small minority.) Repetition of your canonical claim does not make it true. Normal people can see in "Original XML comparison example" under ValueExistenceProof that the first set is '''easier to work with and less clutter''' than the second. I'd bet money most regular developers would pick the first. The addition of nesting serves no notable purpose of the tag model itself. YagNi. Nesting complicates the tag model itself, period. That should be clear to all. Until your it-teaches-bad-habits or violates-canon sort of claims are fleshed out, I'll go with keeping the model simple.

* {How "programmer's minds" may represent values and variables is irrelevant.  I'm interested only in how values and variables are represented in the semantics of popular imperative programming languages.  (It's also what programmers learn in school, so I suspect it is how "programmer's minds" represent values and variables unless they've been particularly forgetful.)  My issue with your definition of values and variables in D1 languages is that your variable has an extraneous "type" attribute that is unnecessary, and your value is missing a "type" attribute that is necessary.  Your solution to this  is to conflate values and variables into a single construct in which you ignore the "type" attribute when you use your construct as a variable and ignore the "name" attribute when you use your construct as a value.  That seems awkward.}

* It may seem awkward to YOU because your mind is entrenched with a certain model '''based around implementer patterns'''. They were to serve machines, not humans. My approach is '''better factoring''' for the particular model and it's expected usage pattern. It's a technique that's too bloated for machine efficiency, but creates a nice bread-crumb-like pattern to make it easier to grok and trace for humans. It's not objectively "wrong" (outside of machine performance scores perhaps). And why get into another WetWare fight? Both sides disagree on assumptions about the target audience's WetWare and neither has solid studies that '''override''' our personal experience, so '''why keep pushing that issue'''? I don't understand you guys. You are beating a dead horse, or at least a horse stuck in an AnecdoteImpasse. Unless you have something higher up on the EvidenceTotemPole than anecdotes about personal experience, why keep harping on the fact the other side "has nothing better than personal experience"? Again, it's throwing rocks from glass evidence houses. Give it up! '''I know you disagree with my assumptions about programmer wetware. You don't have to keep stating that over and over.''' Please, no more WetWare fights without new evidence. Repeating your same points over and over will not convince me. Repetition may work on your mom, but I am not your mom.

* {No, it seems awkward because you're overloading a single structure for two distinct, non-overlapping purposes.  In OO terms, your valvarueiable is a GodClass.  In SoftwareEngineering terms, your valvarueiable exhibits poor cohesion.}

* Are the two concepts objectively distinct, or just your thought habit (or interpreter builder conventions)? Is there a topic that represents your view of "cohesion" in a clear way? 

* {In popular imperative programming languages, they are objectively distinct.  Variables can be assigned; values cannot.  Variables are time-varying; values are not.  Functions return values, not variables.  Etc.  See http://en.wikipedia.org/wiki/Cohesion_(computer_science) for an adequate description of cohesion.} 

* I agree with the "Talk" tab comment: "Cohesion needs to be defined better; Need more examples as well".

* {Cohesion is defined and discussed in numerous references, so I need not elaborate here.  Suffice to say that good cohesion is keeping related things together and unrelated things apart, whereas poor cohesion is keeping unrelated things together and related things apart.  Your valvarueiables are keeping unrelated things together.}

* There are some "modularity" discussions about such on this wiki, but I don't see it relevant here. There are not objectively two separate things. YOU claim there should be two separate things, but they don't have to be two. In system design, one looks at the variations in attributes and makes a judgement call on whether to implement/represent a variation-on-a-theme via attribute differences or make them separate "types" of things (separate entities). In this case, there is not enough variation to justify the second. In fact, there is very little variation, since all such objects are named in my model, per model rules.

* {You appear to be conflating application of your model with the model itself.  In what language are, say, return values from functions named?}

* There appears to be some confusion. The "internal variable" is a feature of the model, NOT necessarily what it is modelling. It may have a resemblance to actual target languages, but for our purposes that's coincidental. The "internal variable" is a gear of the orrery, not a planet nor a direct representative of a planet.

* {Then you're not defining a model of existing programming languages, you're defining a new programming language.}

* Kind of. The model translates the target language into a series of API calls. If you want to call these API calls a "new programming language", I guess I don't have a problem with that. It's a legal modelling technique.

* {Except it isn't modelling anything.  The fact that it's intended to turn some input into the same output as language 'x' doesn't mean it models 'x', it only means it produces the same output as language 'x'.}

* Wonderful, a LaynesLaw loop over "model". It's a ''prediction'' model. If it predicts correctly from an I/O standpoint (and is grokkable to target audience), it serves the purpose it was designed for. It is NOT intended to model typical or common implementation of interpreters. 

* {It's an acceptable "prediction model" if it only considers user input and user output.  As soon as you use source code as input, and you draw connections -- even if only implicit -- between identifiable components of the source code and your model -- apart from just treating the source code as arbitrary, though perhaps rule-based, strings of characters (i.e., just syntax) -- you're dealing with semantics.  As soon as you're dealing with semantics, comparisons between your model's semantics and actual language semantics are inevitable.  It appears that your "prediction model" is actually an attempt to model the semantics of popular imperative programming languages, but it does so with peculiar terminology and a conflation of values and variables.}

* You are making up rules out of the blue. If you can objectively fail it per an objective and clear "semantics" test please do. Otherwise, stop repeating unsupportable claims. ArgumentFromAuthority is not sufficient and your repetition is oh so fucking annoying. If a defective car alarm did the same, I'd blast it to dust with a shot-gun.

* {It fails, for instance, by defining variables and values as the same construct, which implies that we should be able to assign the result of expression evaluation to the result of a function invocation.  By the way, be sure you're using ArgumentFromAuthority correctly.  It's a fallacy when authority is misplaced.  For example, if a former moon astronaut claims that you should listen to his theories on programming language design because he's a former moon astronaut, that's ArgumentFromAuthority.  If a computer scientist with an established background in language design and implementation has theories about programming language design, they should at least be given due consideration, because that's ''actual'' authority on the subject.}

* "Implies"? I don't understand. Just because a given model/implementation may permit the POTENTIAL implementation of a certain feature does not mean we HAVE to use that feature. That's silly. As far as your ArgumentFromAuthority, to some extent you are right, but the proper expert in this situation would be an "industrial psychologist", not an expert at bit-diddling (alone). Further, a real scientist would use stronger and objective evidence and formal logic or something close it, not repetition of vague notions. Or at least realize there is a real gap in existing knowledge on the subject and acknowledge that instead of stubbornly cling to arbitrary pet models (or models optimized for machines instead of for humans). '''Good scientists are not stubborn in the face of weak evidence.''' (A good scientist can still be tenacious at ''finding'' better evidence to back a pet theory, but that's not the same as tenacious insistence of true-ness. Further, language implementation experience may bias one toward specific "thought models" that differ from typical developers, the target audience in this case. They essentially would be a "tainted" WetWare test-case.)

* {Indeed, you don't have to use a feature just because the underlying model supports it, but a model shouldn't support useless constructs either.  I know you've said that combining values and variables "avoids nesting", but it seems rather odd to avoid nesting -- given that programmers are used to "nesting" in all sorts of programming contexts (e.g., code is "nested" in every 'if' statement or loop) -- but conceptually permit oddness like allowing the result of expression evaluation to be assigned to the result of function invocation or vice versa.  Then again, maybe it wouldn't be "odd"; maybe it would be useful, I don't know.  I do know that no popular imperative programming language does it.  Some languages allow you to return a pointer to a variable, but a pointer is a value that references a variable, not a variable itself.}

* Re: "but conceptually permit oddness like allowing the result of expression evaluation to be assigned to the result of function invocation" -- I keep telling you over and over, it '''does NOT do that'''!!! If YOU do that in your mind, that's fine, but it's only happening in YOUR mind. "Conceptually" I'm kicking your vague stubborn ass with large metal boots in my mind. But (unfortunately) that's only "conceptually", not real life. IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT, IT DOES NOT DO THAT.

** {But it does do that.  Your model permits it.  If values and variables are the same -- call them valvarueiables -- and we can assign to valvarueiables, then we can assign to valvarueiables.  What part of your model decides that you can assign to a valvarueiable in once place and not another?}

** I already answered that like 5 times.

* What exactly do you mean by "supports" it? You mean make it easier to implement such (if wanted) than your model does? Not an important issue even if true. Are you afraid somebody is going to bump the source code and accidentally turn on such a feature??? And what exactly are you labeling "useless"?  My variable model itself has a purpose; it's tuned based on careful weighing of many tradeoffs, as already described. You are slinging words around fast and loose. And yes, programmers are used to nested structures, but as a general rule, '''models/notations are best if the most-commonly-used features is made as simple as possible, even if it means complicating other (rarer) issues/parts'''. I keep explaining this rational, and you ignore it. Why? Don't just ignore it, explain why you dismiss it if you wish to actually communicate.  It's done for a reason and I stated the reason, multiple times: it's not "useless"!!!!  The reason given is an applicable design rule. If some other clear rule over-powers it, what is it, and why does it get a heavier weighting? Communicate. 

* Re: "I do know that no popular imperative programming language does it" -- Does what? I told you, syntax filtering would reject your sample "foo()=x" pattern in my model. My model does NOT "do" it either (does not allow, if fully implemented to the parse stage). If you mean none "uses" my variable/value model in general (ignoring the "foo()=x" issue), then you have shown no objective way to measure whether or not they "do" it internally (if we skip implementation, which is shaped by machine-centric issues, not human-centric ones). '''My model leaves NO known I/O-profile difference-maker trail because of the variable model.''' Thus, if it's missing something or has/does something extra, that something does NOT show up in the I/O test. Where is the other objectivity port you are looking at? It does NOT break/fail my "testing device", so I don't know what this function-related complaint is about. What EXACTLY is your complaint in terms of objective failures?


{The interpreter simply evaluates the argument expression and passes the resulting value to typeName().  Then typeName() retrieves the name of the type associated with the value, and returns the name of that type as a string value.}

You have not proven that the "type" should be "inside" the "value". It's only that way in your particular model. You are describing your model, not a universal truth of all working models. I don't dispute that YOUR model does that, so there is no point in describing how you model does it over and over again repeatedly.

{"Type" doesn't have to be "inside" the value.  It only has to be associated with the value, i.e., a value has a mapping to a type.  In a model, a simple and intuitive way to demonstrate an association is by inclusion (i.e, "has-a"), but it's by no means the only way for implementations to work.}

I realize that references and inclusion can be interchangeable implementation choices. But for clarity, it's best a model '''pick one or the other''' and stick with it to avoid confusing the poor reader. I'm using your reference XML samples here, and they are inclusion-based.

{Yes, for modelling purposes inclusion is clear and intuitive.}

I'm assuming inclusion when interpreting your words such as "have" based on your XML. If a variable "has" a value, and this value "has" a type, then it's common to say the variable "has" a type. It should be dirt simple, why is this derailing on the Communications Express?

{There's nothing in a DynamicallyTyped interpreter that will ever make reference to a "variable's type".  In DynamicallyTyped languages, only values' types are ever referenced.  Therefore, in a DynamicallyTyped language, why model a variable as having an explicit "type" property?}

You keep saying that, but you don't demonstrate it. Repetition will NOT convince me of diddly squat. You cannot even demonstrate that "values" objectively exist dynamic language interpreters.

{I demonstrated it at the bottom of ValueExistenceProof, using code.  As for "values" objectively existing, I've deductively proven they exist multiple times.  As further evidence, try defining a model of imperative programming languages without values.  (Obviously, that requires exclusion of values renamed to something else like "anonymous variables", etc.)}

They are "renamed" because you don't like the name? That's not scientific, that's human whim.

{No, it's because values aren't variables.  They aren't variable.}

"Value" has no clear-cut definition such that we cannot verify that claim.

{The most general definition is that a value is the result of evaluating an expression.  A variable is never the result of evaluating an expression.}

"The" result or "a" result? 

{The result.  The result of completely evaluating an expression is a value, always.}

In my model, a "value" is ''a'' result of evaluating an expression, but not the only result (because a tag indicator also results).

{Always?}

Further, if we don't need part X in a given model, why include it? '''We're not obligated to model every computer notion''' anybody ever had.

{"If we don't need part X in a given model, why include it?" is my argument for not giving variables a "type" property in DynamicallyTyped languages.  However, values are needed.  Otherwise, what (for example) does a function return?}

That's an internal issue, not an objective issue. Functions can return pligznoogs inside the model. In my model, the result of a function et al is two-part: the type tag and the "value" (aka "representation"). 

{I don't know anyone who'd claim that functions return pligznoogs either inside or outside of a model.  However, if your functions return a type and an associated representation, they're returning values.  Good.}

If it makes you happier to call them "values", go for it. But, it doesn't serve (help) my target needs.

{It makes me happier if you call them "values" as opposed to some made-up terminology.  Actually, that's not quite true:  You can call them whatever you like, including made-up terminology, as long as I don't have to see it.  If I see your misuse of terminology here or elsewhere, I will object.}

And I'll object to the ugly trade-offs going your route entails. Don't ask what they are again. I've explained 10 times I would estimate. 11 won't change anything.
-------

{Why do my examples -- at the bottom of the page -- not need to make any reference to the type of a variable?}

I don't know how your model works exactly at that level. I cannot comment on that. Specifically, your implementation of "add" is not fleshed out. In your model, eventually you'll have to make a reference such as: variable --> value --> type. It's just a longer way to do what I do, not having the middle-man layer.

{"Add", in most languages, is binary addition, acting on the representation of a value.  In most languages, assuming canonical types, it is implemented by a CPU's machine language "add" instruction.  "Add" does not operate on variables, it operates on values.  In my model, there is never a "variable --> value --> type" operation.  There isn't one in any DynamicallyTyped language.  There is only a "variable --> value" operation and a "value --> variable" operation.}

You have not objectively demonstrated your claim about what "Add" does. 

{I'm not sure what "objectively demonstrated" means in this case.  I do demonstrate how interpreters invoke "Add" at the bottom of ValueExistenceProof.}

As far as the second part, in your model reference, you have the following structure, and it has "type" as a component of "value".
 <variable name="splat">
	<value '''type'''="int" representation="3423"/>
 </variable>
{Sure.  In Category D1 languages, values have a type reference property but variables do not.  Variables simply contain values.}

Nested-ness does NOT de-have-ify in typical usage! How many damned times do I have to repeat this??? In YOUR model, variables contain values and values contain types. Thus, it's fair to say that "variables contain types" using typical usage of "contains" in IT. Nesting does not diffuse such a relationship.

{Nothing in the implementation of a DynamicallyTyped language ever makes reference to a "variable's type", so there's no reason to model it.  Therefore, your model of variables having a "type" attribute is at best redundant, on average misleading, and at worst incorrect.}

It appears to serve the same general function as the "type=" attribute in your XML model for D1. And it is needed because type info is NOT kept "in" your "representation".

{Nor does it need to be.  "Type info" is kept in values.  A value is a pair consisting of a representation and a type reference.}

That's specific to YOUR model, not a universal need in order to match I/O (input includes source code).

{I'd be curious to see how you can match I/O without it, given that every language implementation requires it.  In short, how do you (or the interpreter) know what a representation -- i.e., a string of bits, usually -- is, without an associated type reference?  For example, what does this string of bits represent: 1 1 0 1 1 0?  Should we use string operators on it?  Integer operators?  Floating point operators?}

{Now, what if I '''tell''' you it's an ASCII character or 'char' type?  Or an integer?  Or a monochrome image?  It's only when I tell you the associated type that you (and the interpreter) can recognise that it's ASCII character '6', or the integer 53, or a tiny picture with six pixels.  Without an associated type reference, it can be anything.}

Keep the type tag in the variable, that's how it can know.

{What variable?  How does that work in a variable-less statement like writeln(3 + 4)?  If you claim that 3 and 4 are "variables", then all you're doing is renaming "value" to "variable".  (Erroneously, I might add, because 3 and 4 aren't variable.)}

The parser determines the type, and stores it with the variable. In my model, it uses two hidden variables, which are then processed to assign to the programmer-visible variable. 

{Again, what variable?  There's no "programmer-visible" variable, and "hidden variables" can't be variables, because they're not variable.}

They are internally defined in the model that way. If you don't like it, then think of them as snazzjoomps.

{Then you're using PrivateLanguage for values.  Regardless what you call them, you surely must recognise that whatever-it-is-called has some representation -- usually bits -- but they mean nothing (to humans or machines) without an associated type, as explained above.  Yes?}

So what if I use PrivateLanguage parts inside the model. That's legal. You use "representation", which is also a PrivateLanguage. 

''Actually, "representation" is not a PrivateLanguage. It's a word. But, assuming you meant that "representation" was part of a PrivateLanguage, then you are simply wrong. He's using the standard computer science definition, which makes his use of it part of a PublicLanguage.''

These "standards" of yours are figments of your self-centric imagination. I'm tired of this bullshit! Stop with the goddam '''phoney standards''' already! I'm tired of these games; it's raw stupidity.

I bet next you claim the "standards" are clear if one reads enough obscure Phd books from mumbly professors in expensive universities. Even IF true, the problem with that logic is the '''target audience''' is for the most part not exposed to those sources such that it means nothing to them. Thus, they are not "common" standards, but rather WalledGarden standards (if your book claim were true).

{That's a rant, bordering on AdHominem attack, rather than discussion, debate, rhetoric, logic, or evidence.  It deviates from the key question, which is this: Regardless what you call "values", you surely must recognise that whatever-they're-called has some representation -- usually machine bits -- but they mean nothing to humans or machines without an associated type, as explained above.  Yes?}

* Models can do it different. The sub-topic is "standards".

* {All "standard" meant is that my use of "representation" is conventional, i.e., it's in accordance with standard usage.  If your model "can do it different", then what is it modelling?  Maybe it's not a model, then, but something else.}

* "Standard", yeah right. "Value" is often used in colloquial-land for output-like items without any detectable type indicator. Example, "You forgot to put a value in field X. It's required."

* {For the literal (which is what it is) to be recognisable, a type reference must exist somewhere.  Otherwise, it's just a string.  If the field is in a data-entry form, for example, it's unquestionably built into the form itself or the code behind it.  There's invariably somewhere in the associated database or application code, or the form definition, that the field is identified to be a string, or numeric, or integer, or floating point, or a date, or whatever.}

* But that's often later down the road. It's not of the immediate concern of the speakers in the example. Existence is. Plus, the user usually can't "see" any type mechanism that's behind the scenes (unless perhaps they make a mistake). It's just characters in a box to most users and does not carry any inherent mental type tags/indicators.

* {We're not talking about the user's understanding of the field, but how the program interprets it.  To interpret it, there must be an associated type, even if it's implicitly "string".}

* You mean similar to D2 typing? That gets into the fuzzy territory of "what is a type". D2 style programming often leaves "type checking" to the app programmer, and blurs the line between "types" and "validation". It's hard to call all conditionals that "check" something a "standard" except in a very wide-open way. I consider "type" a vague and continuous concept that shares territory with validation, conditionals, etc. And this doesn't really contradict the traditional definition of "type" because just about any input to any process (operator, functions, class, module, etc.) can be viewed as an operand-operator relationship.

* {Yes, if we assume a field is string, that's similar to D2 typing.  Identifying whether a given literal denotes a value from the set of values described by a type -- what you call "validation" -- is fundamental to every type system.  In Category S and D1 languages, it occurs during LexicalAnalysis prior to run-time.  In Category D2 languages, it occurs at run-time within operators.  There's nothing vague about it, as proven by the fact that interpreters do it; there's nothing vague about a working interpreter.  Anyway, that's not the point.  The point is that for a literal to be recognisable, a type reference must exist somewhere.  If it's not explicit, the implicit type reference is "string".}

* See PageAnchor indirect_types. A form user will not know or care whether the engine behind the form is D1, D2, or DD.

* {Correct, the form user won't know or care.  But, as I wrote above, we're not talking about the user's understanding of the field but how the program interprets it.  To interpret it, there must be an associated type, even if it's implicitly "string".}

* I thought the context was human "semantics", but I cannot find the original context so far.

''Since I can go to just about any website that specializes in computer science and find that it uses "representation" in exactly the same way it's used here, your vulgar denial of it being part of a PublicLanguage is clearly false. Since your target audience also has free access (and in most cases had formal training that includes this use of the word "representation"), your claims that it would mean nothing to them is likely to be false as well.''

No they don't. Representation usually relates to output, not INTERNAL "storage"; or at least it's overloaded to refer to both internal representation and output's formatting.

{"Representation" can refer to output, storage, input, transfer, display, etc.  That's not "overloading" in the sense that one word has different meanings.  It's one word, with one meaning, that can be used in a variety of contexts.}

Almost everything in coding-land is "representation" such that it doesn't distinguish anything and/or is redundant. 

{It's distinguished by context.  If I say my numeric values are represented using the IEEE 754 standard for binary floating-point arithmetic, then we know exactly what is meant.}

Because the standard defines such within or in relationship to the standard. But that by itself doesn't make it a universal truth; it may just be a standard-specific (part-specific) truth similar to the way each programming language gets to define what a "literal" is per its language syntax charts/rules.

{That doesn't contradict what I wrote.}

At best you have a UselessTruth. It doesn't convey anything definitive to the model user. No context of the type you speak of is given in the model itself.

{I'm not clear what you're debating, here.  Every value has a representation.  That is indubitable.}

EVERY attribute in your XML (or tuple or any XML) is a "representation" of something. Calling one in particular "representation" doesn't tell us anything new. "Value" would be the most natural name for it, but you already used that name for something else. 

{As I noted above, the context is important.  In context, the "representation" attribute is the bit string (or whatever) from which, along with a type reference, a value is constructed.}

Well, the "context" doesn't do anything for me. Sure, you can describe what the attribute is for elsewhere, but you could do the same if you called it a nazzblerf.

{That wouldn't make sense.  Without a representation, when an operator manipulates a value, what is it manipulating?  Is it operating on bits?  Individual ASCII characters?  Arrays of Unicode characters?  Something else?}

I don't know. I won't attempt to re-label your particular model.

{My question has nothing to do with labelling or "my particular model".  My question applies equally to every programming language.  Of course, as I've mentioned before, a model can gloss over the representation by skipping any mention of it.  For example, you can describe a value as <value type="int">1234</value>, but every interpreter '''must''' handle 1234 via some representation, whether it's a string of ASCII characters, a string of bits, or something else.}

It may be true that "1234" will be processed somehow somewhere in the various models, but that doesn't mean we should model and/or label such processing/handling in the same way for each model. Consistency would be nice, but sometimes different models have different purposes and are thus built different.

{There's nothing that suggests "processing/handling in the same way for each model".  However, every interpreter must represent values '''somehow'''.  A value without a representation is meaningless; it has no data for operators to manipulate.}

That PREsumes it needs your version of "values" to begin with. A model can use sniggs and klorps for the purpose of what you call "value" if it wants. Your version of value is '''arbitrary''' (or at least weakly guided by colloquial notions.)

{My version of value is not arbitrary.  It's a concept fundamental to how modern computers and computer languages operate, whether you call it a "value" or a snigg or a klorp.  Of course, if you call it a snigg or a klorp, no one will know what you're talking about.} 

By "operate" do you mean actual implementation? If the answer is "yes", then you should know my likely reply by now. If you say "no" and use the word "semantics", likewise. Note that my model has something called "value", but it's not identical to your version of "value". I could instead call that "representation", but then "no one will know what you're talking about".

{Except that I define my use of "representation" at the top of TypeSystemCategoriesInImperativeLanguages, so that it's clear what I mean, and I provide examples to illustrate what I mean.}

But that's do-able for any "private" term/usage. It appears to be a double-standard to me.

{It would be a double-standard if I were advocating a completely wayward term -- say, "intubation" -- instead of "representation", and didn't define it but used it as if it was already familiar.  Instead, I've defined the term and I am using it in the same manner that "representation" is used in numerous texts.  If you find it particularly objectionable, an alternative for "representation" -- specifically where I've used it -- is "data".}

How is the level of wayward-ness or resulting confusion measured? See also PageAnchor tradeoff_rant_48.

{By "wayward", I mean it's largely unrelated to the concept to which it refers.  Would the alternative, "data", be more acceptable to you than "representation"?}

No. I don't know of a better term at this point. "Value" would be the best term in my opinion, but you used it for a different purpose, and thus are stuck with a goofy trade-off. It happens. I doubt that ANY model can both work (predict) AND match well to existing colloquial usage.

{It's hardly goofy.  "Representation" or "data" is conceptually and practically necessary, regardless how it's named.}

Fine, you satisfied the necessity part, but it's still a goofy name. Just about everything in all our models is "data" and "representation" such that it's superfluous.

{In the context in which it used, "representation" is the usual term, though "data" is also used.}

So you claim.

{It's consistent with convention.  See, for example (I chose this at random), http://www.ntu.edu.sg/home/ehchua/programming/java/DataRepresentation.html }

Because it's an overloaded term. It's hard to be "wrong" with an overloaded term (unless one claims it's not overloaded, perhaps.) And the type indicator also has a "representation" in RAM I would note (based on at least one of the overloaded versions). So why are you NOT calling that a "representation" or a "type representation"? It's not any less "representationy" than the other attribute.

* {No, it's consistent with convention because I'm using "representation" in a conventional manner, and it's applicable in numerous areas.  However, my use of "representation" is within a value, so it's a value's representation.}

* "Conventional" perhaps as a stretch in a similar manner to "thing", but it's so open ended as to not say anything. Anyhow, I personally find it awkward. Other WetWare may differ. LetTheReaderDecide, I don't want to bicker about it anymore.

* {My use of the term is quite specific.  In many language implementations, a value's representation is a string of bits.  In the absence of a representation, all values of the same type would be the same (undefined!) value.} 

* Everything in the model data structures (such as XML) is "string of bits" (or bytes). Your "specific" claim is not ringing true to me. 

* {You appear to be conflating elements of your model with a computer-based implementation of the notation of your model.  A value's representation is a string of bits '''in the model''', and it's the only "string of bits" in the model. We don't care (at a model level) how the model might be implemented on some computer system. The representation would still be a "string of bits" if we implemented the model on paper, as long as it's modelling values in a computer system.}

* Your "type" (or it's reference) is not a "string of bits"?

* {In the model, it's an abstraction.  How it's implemented is irrelevant.  It's sufficient (for modelling purposes) to note that it's a reference to a type.  A value, however, requires a representation even for modelling purposes.  Otherwise, it has no data by which one value can be distinguished from another, or added to another, or concatenated to another, and so on.  The representation is necessary to explain how operators like '=', '+', '/', subst(), etc., work.}

* But the "type" also requires a representation somewhere.

* {True, in an implementation.  For modelling purposes, we don't need to consider it unless it's a core aspect of the model.  Values are different because even in modelling them, we need to consider the representation in order to explain how operators like '=', '*', and so on, work.  If we're not going to consider how operators manipulate values, then we can omit the representation.}

* I'm not for omitting them, I'm for finding a better name than "representation". Anyhow, I'm done arguing about this. I find "representation" an awkward and unhelpful choice and expect others would agree, but this is just another WetWare AnecdoteImpasse and I'll leave it there. LetTheReaderDecide.

* {It doesn't matter to me whether you like the name "representation" or not.  It's the standard term, in the context of a value, for the concept it identifies.}

* Standard for who? My target audience is regular programmers, not interpreter builders. 

* {Standard for ComputerScience, SoftwareEngineering, and programming in general.}

* In the way it's usually used (found in the wild), YOUR usage/purpose of it is awkward. If you disagree, so be it. LetTheReaderDecide.

* {What do you mean by "it is awkward", and what does that have to do with how it's "usually used"?  I've used it how it's usually used.}

* "How it's usually used" is too vague for me to process in a useful way.

* {A representation is the raw data -- the string of bits or characters -- that underpins a value.  That, along with a type reference (either implicit or explicit) to identify what type the raw data belongs to, is what makes it possible for computers to manipulate values.}

* Sometimes "representation" also means the "output format". Example: "We are going to represent numbers in roman numerals".

* {Yes, it does, and in the context of a value, "representation" means the raw data -- the string of bits or characters.}

* That "context" is not so clear.

* {In my descriptions on TypeSystemCategoriesInImperativeLanguages, "representation" is an attribute of a Value structure.  I'm not sure how much clearer the context can be.}

* That's fine if you allow model-specific descriptions to define or clarify something. Just make sure you extend such courtesy to other models.

* {I don't know what that means.}

* It means don't complain if other models rely on descriptions to clarify field, slot, or part names that may not be immediately self-explanatory or confusing to you.

* {I have no objection to models that use descriptions to clarify parts of the model.  Where have I objected to descriptions, and what does that have to do with my use of "representation" in the context of values?}

* There have been past related issues. I don't revisit them, but merely ask you to remember your promise here.

* {I don't know what that means.  Could you be more specific?}
 

[It's easier to be wrong with an overloaded term. If there are no overloads, then you know which one to use since it's the only one available. Anyway, why do you think that we don't consider a type representation a representation?]

How is that easier to be wrong? Perhaps you mean easier to be ambiguous. If you "considered" it, it's not showing up in your model (per attribute labels etc.)

[Did you not read what you responded to? The explanation is part of it. And what makes you think it didn't show up in the model? In the case in question, the type would be one of the values which would consist of the type "type" and a representation of said type.]

Yes, Sir, I did read it. It didn't address my question the way I interpreted it. And if the explanation/documentation is sufficient, then why bitch about my attribute labels? The explanation can be used to "take care of it" there too. You guys have a double standard.

[I didn't respond to a question. I responded to your claim, "It's hard to be "wrong" with an overloaded term (unless one claims it's not overloaded, perhaps.)". I don't recall anyone (except you) saying your model couldn't "take care of it". The reason we've complained about the attribute labels is that it appears to make using your model more complex while obfuscating the actual semantics.]

The non-nested structure is ''blatantly'' simpler to me; slam dunk; but I will agree that some people have some really odd and unpredictable WetWare, at least relative to mine such that "simple" is largely subjective. Objectively, it's less characters, if you care. And "actual semantics" has yet to be scientifically isolated such that verifying your "obfuscating" claim is not possible at this time, as already discussed. As far as the overloading issue, perhaps an example would help illustrate what you are trying to convey.

----

{Why is it sufficient, in a DynamicallyTyped language, to both model and implement variables using precisely two operators: "void assign(variable_name, value)" and "value retrieve(variable_name)"?}

That's specific to your model, not necessarily a universal truth. Your model can name the internal parts whatever the hell it wants to.

{This has nothing to do with names, and everything to do with the semantics of popular imperative DynamicallyTyped programming languages.  In all of them, variables are implemented using some equivalent to the two operators above.}

You have not given clear evidence for that claim.

{I encourage you to examine the examples at the bottom of ValueExistenceProof, which demonstrate that variables require no additional operators.}

Sorry, I don't see it. Your notation is not clearly defined as given.

{It's no more a special notation than you've used on TopsTagModelTwo.  It's simply pseudo-code, using a Javascript-like syntax and arrows to indicate return values, as is commonly done in descriptions of algorithms.}

I'm only passing around scalars, not structures. You seem to be passing (poorly defined) structures, which hides details. 

{The two structures -- value and variable -- are defined at the top of TypeSystemCategoriesInImperativeLanguages.}

It's not fleshed out enough to clearly know what it's doing with the structures.

{Exactly what's being done with the structures is described at the top of TypeSystemCategoriesInImperativeLanguages.}

That's not "exactly", that's fuzzy. I already dissected individual words from there one by one and demonstrated multiple valid interpretations. You conveniently forgot?

{No, but your "dissection" was trivially refuted at the time.}

That's not the way I remember it ending. I remember you admitting that English is inherently vague, and that's why other notations are needed and why you added more sections to your model writeup. And you haven't proven that your model is the canonical model of most human programmer heads. I don't dispute it may "run", I dispute it's THE proper model.

{My additional sections used a semi-formal notation to eliminate any possible misunderstanding of the English descriptions at the top of the page.  Thus, they trivially refuted your "dissection".}

It's not clear to me, and appears to be an arbitrary model instead of a necessary model.

{I'm not sure what you mean by "an arbitrary model instead of a necessary model".  As for being unclear, I can only suggest reading it again, and if you find something unclear please ask and I'll explain, clarify, or improve it.}

Asking you for clarification is like asking Ted Nugent for manner lessons.

{What do you mean by that?}

Somewhere I described the usual pattern of what happens when I ask you for clarification. I'll see if I can re-find it.

{Yes, please do.}

FractalVagueness is similar to it.

{FractalVagueness is fiction, and so not particularly helpful.  If you could show what happens when you '''actually''' ask me for clarification, that would be more helpful.}
----

{Why does language documentation typically contain phrases like, "[this language] is a dynamically typed language. There are no type definitions in the language; each value carries its own type. ... Variables have no predefined types; any variable may contain values of any type." (From http://www.lua.org/pil/2.html)} 

Typically? Why did you have to use obscure Lau to get an example instead of say Php or JavaScript or Python? I can't tell if that's common from one sample. And like I mentioned elsewhere, "literal" and "value" are often used interchangably. Literals *do* carry type-related info. And maybe Lau was implemented using something close to your model, and the writers reflected that. But that doesn't make it the only valid prediction model. 

{Lua isn't obscure; it's commonly used for scripting, particularly in videogames.  For references related to languages, I've been choosing them entirely at random.  I find it personally amusing to choose a random language, and then (always!) discover a reference in its documentation that supports the point I want to make.  I know I can do that because I know that the semantics (and hence the documentation) will invariably follow convention.  Except for the PHP documentation, which confusingly (and peculiarly) conflates values and variables in a number of sections.}

I've never seen Lua used in the many companies I've worked for or consulted in. 

{I guess you've never worked in the videogame industry. See http://sites.google.com/site/marbux/home/where-lua-is-used }

"Value" is overloaded such that it's used multiple ways. If it's used 2 different ways roughly 50% of the time for each way, then 1 out of 2 usages will fit your pet version and be relatively easy to find an occurrence of. You'd have to demonstrate that roughly 3/4 of all occurrences use your pet version to have a realistic claim of it being canonical. CSV has "value" in the very name, and it lacks a type indicator component, for instance. (It should be "comma-separated literals" if we use terms usually associated with programming languages, but '''"value" is a loose term'''. That's just the way it is.)

{I've not seen any evidence that "value" is used for anything except values.  "Value" is sometimes used to refer to literals (as in CSV), but that's reasonable -- literals '''always''' denote values so it's an appropriate shorthand.  Literals, in context, always have a type indicator component which is determined by context.  The type indicator depends on the grammar of the system that reads the literal.  For example, in most imperative programming languages, 123 denotes an integer value, 123L denotes a long value, 123.5 denotes a floating point value, and so on.  In short, the syntax unambiguously denotes the type of the literal, and hence the type of the value it denotes.  (By the definition of "string", every literal is a string.)}

There's a difference between saying "Doing X works" and "Doing X is the ONLY way to make it work". There's also a difference between saying "some languages define X as Y" (or document as) and "all languages define X as Y".

{True, but popular imperative programming languages are consistent in their semantics, and I know of no alternative semantics that offer any beneficial alternative to the conventional model described at the top of TypeSystemCategoriesInImperativeLanguages.}

Your version of "semantics" is only in your head. It hasn't been objectively isolated and rigor-atized. Stop assuming your head is the reference head of the universe.

{I suggest you randomly sample the documentation for a variety of popular imperative programming languages, read some introductory ComputerScience textbooks, and examine various on-line sources (e.g., http://www.cs.umd.edu/class/spring2003/cmsc311/Notes/Data/repr.html or http://en.wikipedia.org/wiki/Computer_number_format etc.) for evidence that my version of "semantics" is in a lot of heads, not just mine.}

From your "repr" link: "Representations allow us to write values, which are an '''abstract idea''', in a concrete, preferably, compact way." (Emphasis gleefully added.)

"Abstract idea" == Head stuff! Kapowww! Right in the kisser! Plus, it contradicts your usage of "representation" because it's not meant to be "external" in your model. Further 2, it does not say types are "inside" values.

{As noted above, types need not be "inside" values.  It is sufficient that they be associated with values, i.e., that there be a mapping between values and types.  Whether this is done via inclusion or composition (i.e., "has-a") or some other mechanism is an irrelevant detail, though inclusion or composition is convenient and intuitive for modelling purposes.  Note that many "abstract ideas" in programming have concrete manifestations.  "Variable" is also an abstract idea, but a typical imperative program is full of them.}

* Manifestations are not the same as "abstract ideas". Manifestations are ''shaped'' by abstract ideas, but that does NOT mean they ARE abstract ideas. As far as your "associated with", stick with one and only one representation to avoid confusion. If you want to use references instead of containment, then change your XML model to show that. No flipping. As currently given in your write-up, variables "contain" types in your XML, per common English usage. Nested-ness does not normally disqualify containment in common English usage.

* {Whether "containment" or "references" are used doesn't matter, really.  I'd prefer to stick to "associated with", as it avoids any whiff of implementation strategy that may be implied by "containment" or "references".  Again, that variables "contain" types via a transitive association of variable --> value --> type (such that variable --> type) is -- I suppose -- trivially true in concept, but completely irrelevant and pointless.   As noted elsewhere, in DynamicallyTyped popular imperative programming languages, every variable reference that isn't assignment retrieves the variable's value.  If that wasn't true, something like typeName(v) where v is a variable would be fundamentally different from typeName(3 + 4).  In other words, we'd need one implementation of typeName() for variables, and a different implementation of typeName() for expressions.  Instead, we simply provide one implementation of typeName() that works on values.}

* See above near "This is a definition question, not a quality question."

* {See my response there.}

PageAnchor Ratio_01

And "a lot of heads" may not matter. It's the '''ratio''' that's important. For example, if 50% of typical programmers use head model X and 50% use head model Y, then the choice of X selected over Y, or Y over X probably won't make much difference (all else being equal). It only becomes notable if it approaches around 70%. And even then, other trade-offs and conflicts might come into play such that it's a weighing game to make the least evil compromise. It would have to approach around say roughly 85% before other tradeoffs should probably be ignored and popularity alone dictates the model. -t

{You claimed that "[my] version of 'semantics' is only in [my] head," so I demonstrated otherwise.  What percentage of heads "my" semantics happen to appear in is irrelevant.  It is sufficient to note that they are by no means unique to my head.}

Representations can be "outside" the head, but they are only lossy projections. A painting of "anger" is not anger itself.

{I'm afraid I don't understand your response.  "Lossy projections"?  "A painting of 'anger'...?"}

Where explicitly did you "demonstrated otherwise"? Yes, notions impact objective things, but that's not the same as saying notions ARE objective things.

{I "demonstrated otherwise" in the paragraphs above.  You claimed that "[my] version of 'semantics' is only in [my] head," so I demonstrated otherwise by providing links to documents and sources that share the same semantics.  Thus, they are not "only in [my] head".}

No they don't. They call it an "abstract idea", meaning it's a concept in human heads.

{You appearing to infer something from the document that isn't there.  There is nothing in the document to suggest that values exist only in human minds.  Values are certainly an "abstract idea", but they're also concrete, just like "number" is both abstract and something implemented by machines.}

When something is turned into an implementation, it's RARELY referred to as an "abstract idea". YOU are the one who is "infer[ing] something from the document that isn't there". You read wrong! Your reading is out of step with average humans. 

{A "number" is commonly referred to as an "abstract idea", yet every computer implements them.}

Like I said, a painting of "anger" is not anger itself. The computer model is a projection of an abstract idea, not the abstract idea itself. Everybody knows this except YOU. Symbols represent abstraction ideas, but symbols by themselves are not ''equivalent'' to "abstract idea". A cave painter can paint a scene depicting "hunting". Hunting is an "abstract idea", but the painting is not hunting itself; it's merely a representation of hunting. 

Similarly, if the hunter draws hash marks to track kills, he/she is turning an abstract idea (kill count) into a representation of that abstract idea. The hash marks represent the count, but they are not equivalent to the count.

{So you're arguing that computers don't implement numbers?}

Where did I say that? I'm saying implementations are not abstract ideas themselves but a representation of abstract ideas.

{Yes, of course.  That's trivially true.  Values are both abstract ideas ("think of a number") and concrete.  Functions in C#, for example, return values.}

They are? Can I see them?

{Sure.  Fire up a debugger, call a function and watch as the return value is pushed onto a stack by the callee and popped by the caller.  If that's not a value, what is it?  Ignoring the debugger, look at the semantics:  What does a function return?}
 
It appears we interpret that passage differently. I interpret it to mean that the representation is a concrete manifestation of a mind concept, which is referrred to as an "abstract idea" in that passage. It's rare that a computer is said to "have an idea", but it is common to say that "computers can represent ideas" the same way that hash marks on caves (can) represent numbers.

{Yes, this appears to be a matter of interpretation.  I saw nothing in the article that suggested values don't have reality in a computational system.}

What do you mean by "have" here? A specific representation of ideas, yes. But there are usually multiple diff ways to represent the same idea. And even if the writeup doesn't directly contradict your interpretation of "abstract idea", it doesn't shore it up as the ONLY interpretation either. It does NOT provide an unambiguous definition of "value". Thus, the writeup may not contradict your notion of "value", but it doesn't contradict mine either (that it's overloaded).

{I think this has diverged far from the original point, which was simply this:  You claimed that "[my] version of 'semantics' is only in [my] head," so I demonstrated otherwise by providing links to documents and sources that share the same semantics.  Thus, they are not "only in [my] head".}

I don't see the share-ness. I will agree that your interpretation is often not ruled out in such sources, but neither are other interpretations. English often sucks for tech doc; that's just life.

{If my "interpretation is often not ruled out in such sources", I'll take that as recognition of the fact that the semantics in question are not "only in [my] head".}

No, that does not follow. It does not establish a CLEAR meaning of "value" nor "abstract idea". Not ruling out X does not mean X is true. I cannot rule out that Santa Claus exists, but that does NOT mean he does.

{What "does not establish a CLEAR meaning of 'value' nor 'abstract idea'", and why does it matter?  The sources I chose were intended only to demonstrate that I am not alone in my interpretation of programming language semantics, contrary to your original claim.}

It doesn't contradict EITHER of our claims because it's fucking vague! To me "abstract idea" usually means something in human heads, not machines. But it's not 100% established in the writing such that I cannot claim it with 100% certainty. But it is '''a good illustration of how crappy existing writing is about type-related issues'''. Perhaps it was meant to convey a general notion, not scientifically valid vocabulary and related tests for matches (falsification). Without the rigor, it's '''like a Rorschach test''': each of us projects our world view into the fuzzy gaps in the writings.

{You obviously found it more vague than I did.  No matter, it's merely one example among thousands I could cite to show that I am not alone in my interpretation of programming language semantics.}

No, the actual text is the evidence, NOT your interpretation of it. And the text itself does not clearly back your interpretation of it.

{Your interpretation of that particular article doesn't matter.  It's merely one example among thousands I could cite to show that I am not alone in my interpretation of programming language semantics.} 

The article does NOT back YOUR particular interpretation of the phrases and terms it uses. The text in the article is the objective subject of analysis, NOT your head's version of it. The fact that it does not rule out your interpretation is not the same as verifying your interpretation to be fully accurate. It doesn't rule out my claim that "value" is overloaded or vague. Further, some sources may use it one way, and some sources another. "Value" currently lacks a clear-cut scientific definition.

{"Value" is defined at the top of TypeSystemCategoriesInImperativeLanguages, and its use is consistent with convention.  Again, your interpretation of that particular article doesn't matter.  It's merely one example among thousands I could cite to show that I am not alone in my interpretation of programming language semantics.}

The first sentence I agree with. The rest I don't. The cited sources do not validate that YOUR interpretation of the sources is canonical. They only show it's possible. Possible != Canonical. And this can happen with overloaded terms. A thorough analysis would look something like this:

  Total occurrences of "abstract idea": 983
  Total occurrences that can be interpreted as happening on machines: 684
  Total occurrences that can be interpreted as happening in human minds: 594
  Total occurrences that are clearly happening only on machines: 85
  Total occurrences that are clearly happening only in human minds: 92
  Total occurrences that are clearly happening in both: 36
And then each number can be back-tracked to the source document via detailed reports.

{There is no need for such a detailed analysis, unless you're doing research on descriptions of programming language semantics based on literary analysis.  (Which might be an interesting piece of work, by the way.)  All that is required is '''one''' document not written by me, that shares my interpretation of programming language semantics, in order to demonstrate that I am not alone in my interpretation of programming language semantics.  As it turns out, the majority of popular imperative programming language manuals would qualify.  That, of course, has nothing to do with what is canonical or not, but then this section had nothing to do with what is canonical or not.  It was solely about disproving your claim that "[my] version of 'semantics' is only in [my] head."}

* You failed. You have not proven without a doubt that it shared your interpretation. At best you established your interpretation is one possibility, among multiple, of interpretation paths.

* {Clearly, I have not proven '''to you''' that the '''one article''' shares my interpretation.  That's fine.  I did provide ''two'' links.  The other was http://en.wikipedia.org/wiki/Computer_number_format }

* "Value" is vague in both. Note this statement: "A computer number format is the internal representation of numeric values in [computers or machines]". To me, "representation of" implies it's a '''projection''' of a value, not the value itself. But I will not attach any rigorous meaning to "of" there; only give my own interpretation. A projection of an idea is probably lossy in that it's not a perfect replacement for the original or source "idea" in the human mind. It only has to be good enough for the projection's intended purpose, which is usually communication with a machine or other person(s). You are welcome to interpret "of" differently, but I don't have to recognize your interpretation unless proven without a doubt to be the only valid interpretation. -t

* {What is a "projection of a value"?}

* I'm at a loss for another way to describe it at this time. Many human ideas don't have any canonical notation.

{As for determining whether or not there are canonical popular imperative programming language semantics, that is also trivially done:  Simply note in how many popular imperative programming languages the statement "a = foo() + 3 * c;" has the same semantics.  (Hint: it's all of them.  Those with differing syntax still possess a semantic equivalent, i.e., there's some syntax that allows you to specify, in one statement, "multiply the value in variable c by 3, add it to the result of invoking function foo, and store the resulting value in variable 'a'".}

Same syntax is NOT the same as same semantics. You have not established a way to objectively measure semantics. They appear to be a figment of your imagination.

{Indeed, same syntax is not the same as same semantics.  I never said it was.  What I wrote is that in every popular imperative programming language, the same Algol-derived syntax '''has''' the same semantics.  In every popular imperative programming language, the syntax of "identifier <assignment symbol> expression <end-of-line>" means "store the value resulting from evaluation of the expression in the variable named by the identifier."  I don't know of any popular imperative language where that syntax means anything else.}  

{If semantics are a "figment of [my] imagination", then interpreters must be imaginary too, because without semantics all we have is syntax recognition.  If all we have is syntax recognition, then we can successfully recognise that syntax like "identifier <assignment symbol> expression <end-of-line>" is correct, but the interpreter won't be able to do anything with it.  Semantics are, quite simply, what the interpreter '''does''' to the bits and bytes in the machine, given statements that have syntax like "identifier <assignment symbol> expression <end-of-line>".}

Yes, semantics ARE figments of imaginations. They are an "abstract idea" in human minds. Computers process algorithms, not semantics ''directly''. Computers don't have ideas and notions (outside of AI). And even if I agree that semantics may exist inside machines, for the sake of argument, the claim that the semantics for language A are the same as those for language B is not scientifically measurable at this point. '''There is no clear and useful metric for the same-ness of two or more instances of semantics'''. SUCH TESTS DO NOT CURRENTLY EXIST. We ''can'' measure and compare syntax and grammar rules for computer languages and identify similarities via pattern matching criteria, but there are no known comparable tools for "semantics".

{You are confusing "semantics" as used in the context of human language -- which is about what human language means to human brains -- with "semantics" used in the context of programming languages -- which is about what programming language "means" to computational machines.  Programming language semantics are about what the code does with the machine.  The tools we use to compare semantics are formal languages, set theory, DenotationalSemantics, etc., or even pseudocode and human language.}

* The last two are vague or non-unique (different ways to describe/implement the same result). I cannot say if set theory and DenotationalSemantics are unique or not, but they do NOT reflect how typical developers reason about languages.

* {Considering language semantics in terms of formalisms is generally the domain of pure ComputerScience, as human languages are sufficient to explain programming language semantics for SoftwareEngineering purposes.}

** No. I demonstrated how your (plural) writeup used English words that were too open ended and you (plural) appeared to agree eventually, and offered a more formal notation as an alternative or supplement to English. Did you forget about that?

** {Not at all.  It's why academic writing relies on formal notations.  I would argue that our discussions here are far closer to pure ComputerScience -- particularly discussions of ComputerScience pedagogy -- than they are to typical explanations of programming language semantics for SoftwareEngineering purposes.  If I were going to explain how some function works in PHP, English would almost certainly be sufficient.  It's certainly sufficient for the PHP manual, and even as badly written as it is, a lot of PHP programmers seem happy to use it.}

** One can learn to use dynamic typing & languages via trial and error, and that's one of their selling points: incremental absorption (including LimpVersusDie). But that's not necessarily the same as using a rigorous mental or computational model. We've over this already. Anyhow, the tag model offers the possibility of using existing knowledge (XML or tables and imperative code) to create models. No special academic notation needs to be learned. It has two nice features: '''1) Does not rely heavily on English and 2) Does not rely on arcane notations.''' Your model cannot claim these. The down-side is that it may not mirror actual internal interpreter construction as well. Let the user decide which trade-off path they want. '''VIVA CHOICE'''.

** {I don't really care what notation you use; it's relatively unimportant.  My objection is to contradictory or unfamiliar terminology (e.g., "anonymous constant", or "tag" when it would be more helpful to clarify existing terminology), or confusingly defining variables as having types in DynamicallyTyped languages when one of well-known distinguishing characteristics of DynamicallyTyped languages is that variables do not have types.}

** As far as term choices, see PageAnchor tradeoff_rant_48. As far as "variables do not have types", they DO have types in YOUR very own XML model of D1 variables, as I've pointed out 17.28 times already. They are objectively THERE (by most normal people's use of "have"). If you want to reinvent "have", do so in your own closet, I don't want to see it.

** {That's not the meaning of "have types" to which I object.  Your model of variables in D2 languages '''has an explicit type attribute''' in variables, despite there being '''no apparent need''' for an explicit type attribute in variables.  My "model" of D2 languages '''does not have an explicit type attribute''' in variables, because there is '''no need''' for an explicit type attribute in variables.}

** It does? Where? If so, it's a mistake on part, or a misunderstanding.

** {Muy bad -- I typo'd.  This is what it should be:}

** {That's not the meaning of "have types" to which I object.  Your model of variables in D1 languages '''has an explicit type attribute''' in variables, despite there being '''no apparent need''' for an explicit type attribute in variables.  My "model" of D1 languages '''does not have an explicit type attribute''' in variables, because there is '''no need''' for an explicit type attribute in variables.}

** Your model ALSO has an explicit "type" attribute "in" variables for D1 languages; it's just embedded a layer down. Is this the "nesting fight" starting up yet again?

** {Given typical OO definitions like "class Variable {String name, Value value};  class Value {Type type, Representation data};" do you think any programmer would claim that Variable has "an explicit 'type' attribute"?}

** If talking about an instance, '''yes'''. I believe "has" or "contains" would be acceptable or even common. But it would be an interesting language experiment to see if the notation used changes their response. (Hey, what's with the word "explicit"? You are moving the goal posts. Caught!) In stereotypical OO composition, a house may "contain" a garage in a similar manner, and the garage would contain a garage door. Since OO is often supposed to model the real world, a house "has" a garage, which "has" a garage door. Thus, it's common (or at least acceptable) to say the house "has" a garage door. Some even call such a "HAS-A" relationship in OO, versus an IS-A relationship of direct inheritance. I don't know why you are making a big deal about this anyhow; there are different ways to factor/arrange data structures for essentially the same info. Or are you going canonical on me again?

** {I don't think anyone would say that Variable has "an explicit 'type' attribute", so I don't think "has" or "contains" in this case would be either acceptable or common.  But never mind.  I'm using the word "explicit" to make it clear what I mean.  Your model is equivalent to "class Variable {String name, Value value, Type type}; class Value {String value};"  Note how you have an explicit "type" attribute in Variable?  See how that differs from "class Variable {String name, Value value}; class Value {Type type, Representation data};"?  Now, what's different about Variable between the two models?  How would '''you''' describe it?}

** Yes, "never mind" that; we've been over it before, producing an AnecdoteImpasse. How would I describe the difference? In OO terms? One uses a layer of composition and the other doesn't, factoring the attributes to the top layer.

** {By "factoring the attributes to the top layer", you wind up with variables having a "type" attribute that isn't needed and values missing a "type" attribute that is needed.  Unless, of course, you turn values and variables into a valvarueiable, in which you ignore the "type" attribute when you use it as a variable and ignore the "name" attribute when you use it as a value.}

** What's wrong with that? And what do you mean exactly by "need"? For what goal? Use what you need and don't use what you don't need. That's dynamic thinking, which is not "evil", just different from static thinking. (Static designs are usually better machine-performance-wise I would note, but we are NOT optimizing for that in this model.)  And in my model, every "value" is a variable. It may be inaccessible to the "outside", but inside the model it's just as accessible as any other variable and is addressed and handled just like the "external" variables. (We can play with it to learn). Thus, I don't have "values" of your kind in the model whatsoever. It's not needed, period. I agree such address-ability of "things" is not a necessity to "run" such a model/interpreter, but it's a '''human grokking aid'''. And when we introduce that aid, the need for a non-named "value" (or your kind) goes away such that we factor out a level. Logical, rational, clean. We don't need your kind of indirection/nesting in THIS model, so we get rid of it. I see nothing wrong or evil about that. It's Factoring 101. If we are concerned with machine performance ONLY, then I agree such factoring is a poor choice because machines don't need "labeled values" (or whatever you want to call them) and they just consume resources. That's probably why the "standard academic model" factors the way it does. Neither approach is "wrong", it's just optimized for different purposes. --top

** {What's wrong with it is that you're overloading a single structure for two distinct, non-overlapping purposes.  In OO terms, your valvarueiable is a GodClass.  In SoftwareEngineering terms, your valvarueiable exhibits poor cohesion.}

** Isn't "distinct" and "cohesion" being discussed already in different parts of this document? I don't want to reinvent those discussions here. (Search "Sorry, I don't see redundancy" for "distinct".)


* Re: "which is about what programming language 'means' to computational machines" -- Again, you appear to be anthropomorphizing machines. Non-AI machines (software) DOES NOT SEE/FEEL "MEANING". Meaning is a word for people's heads, not computer heads. 

* {I put quotes around "means" in "'means' to computational machines" for precisely that reason.  "Means", in software terms, is certainly not about cognition; it's a deliberately anthropomorphic shorthand for what programming language semantics are really about:  What the code does with the machine.} 

* That's too nebulous for me to process, measure, or compare. The widest interpretation of "does" only requires the I/O to match (including source code) and says zilch about anything outside of those 3 things.

* {Is "a = foo() + b;" too nebulous for you to process?}  

** I meant your description and wording, not the expression. Tell me, exactly how is "semantics" different from "algorithm" in a machine/software?

** ''An algorithm describes "how", the semantics describe "what".  An algorithm describes the steps or instructions (which themselves can be described in terms of algorithms and semantics) used to implement the semantics.  The semantics of assignment "<variable> := <expression>" in Pascal is "store the result of evaluating the expression in the variable".  Semantics describe the effect of such a statement, they also describe the parts.  What a "variable", "value", "type", "expression", "evaluate" is, is semantic.  By comparison, syntax merely states that a sequence of characters may be followed by a certain symbol which may be followed by a certain set of other symbols and sets of characters, etc.  An algorithm is a sequence of steps, e.g., "1. push the value represented by the first literal to the stack. 2. push the next ... blah blah blah".  Semantics describes what a "literal" is, what a "stack" is, what a "value" is, etc.  By "describes", I don't mean "provides an English definition", I mean it's what these things are in terms of machine addresses, bits and bytes, or whatever other programmatic mechanisms are provided to the implementer by the machine environment.''

*** "How" is implementation, and there are multiple qualifying implementations such that "how" does NOT provide us with a canonical view of "semantics" or anything else resembling "semantics".  And Pascal does not talk like that, at least not before a few drinks. That's YOUR personal interpretation of a code snippet, or at least one of many interpretations or translations into a pet head model or pet terms. Words like "store" or "save" are relative. Re: "What [X] is, is semantics". But there is no known canonical objective "is" for your listed X's, except as described in a particular language's syntax rules. '''The stuff in between the I/O nodes and syntax rules is not objective!'''. Your view of them is not canonical; it's personal and unique to your head, or at least not universal Again, you are mistaking your personal head models as objectively reality, without realizing it. And the last sentence makes no sense to me. "Is" is a crazy word in virtual-land.

*** ''What does Pascal's "<variable> := <expression>" mean to you?  What are the "multiple qualifying implementations" that apply to "<variable> := <expression>"?  Not sure what the rest of your argument is about -- philosophical debates about the meaning of "is" are irrelevant; what matters is what machines do, and how programming languages are used to allow us to express what we want machines to do.  That's what "semantics" is about.  As for the "stuff in between the I/O nodes and syntax rules", it is as objective as something gets:  In every compiler or interpreter, it's implemented in code.''

*** I'm not sure how to turn your "what does...mean to you" question into rigorous English. Thoughts are thoughts. Colloquially, I'd say "the variable receives the results of the expression". And if you asked me to define/describe "results", I'd probably colloquially say that a "result" has at least a type indicator of some kind, and a thing that could be called a value, representation, data, field, byte sequence, string, and/or literal, but have no solid label for it. I'd lean toward "value" or "literal", but don't claim them ideal. How the type indicator and the value/literal are packaged together (or kept separate) is implementation-specific. There is no single "right" way to package them in terms of getting the right final result. "Result" is just a handy short-hand for the "stuff emitted". It's comparable to saying "the mailman/mail-person delivers mail". "Mail" may be one package, a thousand letters, or all kinds of different postal items. Saying "mail" allows one to be vague about the nature of packaging and contents. "Mail" is the stuff the mail-person delivers. (Postal rules define what's considered a valid delivery items, I would note. Not sure if there is a usable equivalent for our purposes.) In general, '''I kind of visualize the expression squirting "stuff" into the variable''', the "stuff" looking kind of like half glue and half gel pill. I don't concern myself with the nature of the "stuff" unless a specific question down the road requires opening or digging into the "stuff" for specific parts, like a type indicator.

*** ''So, in a somewhat roundabout way, you're saying "<variable> := <expression>" '''does''' mean "store the result of evaluating the expression in the variable"?''

*** It's not about "is" but it is about "do"? Okay, define "do". And please be careful about the implementation versus results issue that keeps coming up over it. '''Make sure it's clear how one knows if one "do" is equivalent to another instance of "do"''' this time around.
*** Re: "allow us to express what we want machines to do" - But we express it in algorithms. Our ideas/notions/semantics are translated, in part, into algorithms. The output of this coding/designing process is algorithms, not semantics. (I say "in part" because it's probably a lossy process: the algorithm is probably not fully equivalent to our thoughts.)

*** ''In a simplistic sense, semantics are the mapping between language statements and algorithms.''

*** Do you mean the algorithms used by interpreters, or the algorithm specified in the app source code? If the first, there are multiple possible algorithms for interpreters such that the "semantics" wouldn't be canonical.

*** ''I mean the algorithms used by interpreters.  It is precisely the fact that multiple possible algorithms all do the same thing for a given semantic that we distinguish syntax from semantics from algorithms.  Syntax says, "<identifier> := <expression>".  Semantics says, "evaluate expression and store resulting value in variable".  Algorithm says, "1. pop blah from blah; 2. push bleat onto blah; 3. Flip bit blah in... etc..."''

*** Re: "It is precisely the fact that multiple possible algorithms all do the same thing for a given semantic that we distinguish syntax from semantics from algorithms." -- Producing the same output per given inputs (for all sets) means the "semantics" are the same? Are you sure you want to back that statement? It's a very curious claim. Or are we again using a different interpretation of "do". You seem to be creating a circular relationship between "semantics" and "do" such that using one to define/explain the other creates confusion, a typical result of circular definitions. Re: "semantics says...". Semantics does NOT talk. You are mistakenly anthropomorphizing it again. Simon says, "stop mistaking your head model for universal truths". Obey Simon! I already showed an '''alternative way to describe such expressions in English''' such that yours is not unique, and thus your English example does not prove canonization.

*** ''Producing the same output per given inputs for '''all''' inputs and outputs (note the emphasis on '''all''') means the semantics are the same, but only '''if''' we treat the system as a black box.  There is no circular relationship between "semantics" and "do".  What languages "do" is part of their semantics, and the descriptions or definitions of their component parts -- what variables are, for example -- is the other part of their semantics.''

*** Their English descriptions are vague and/or overloaded. We've been over that already, dissecting specimens and finding ambiguities etc. Words like "in", "has", "is", "denotes", etc. don't provide the rigorousness needed for your claims.

*** ''Sure they do.  For the sake of discussion -- which this is; we're not trying to formulate a proof, for example, which would require mathematical rigour -- words like "in", "has", "is", "denotes" are fine.  The alternative is to switch to purely mathematical notations.  Is that what you'd prefer?''

*** I believe I've demonstrated why such words are problematic, especially regarding the "nested" debate. Anyhow the 3rd alternative is to not get too caught up in definitions and make an imperative model in familiar languages or pseudo-code whose "processing" can be followed. Show instead of tell (or in addition to). English only goes so far (to most).

*** ''No, you've '''claimed''' such words are problematic, and have quibbled over it, but you've never demonstrated an actual problem.  I have no objection to pseudo-code illustrations, however, and have demonstrated such near the bottom of ValueExistenceProof -- see Example 376.''

*** I believe you yourself admitted that English was vague and suggested "formal notation" instead. I don't remember where the topic is, I'll look for it later. Example 376 is not clear enough to me. For one, it's passing poorly-defined compound structures around, and it's not clear what is being done with these structures.

*** ''For the rigour needed for formal proof, English is vague.  Even for certain discussions, it may be too vague.  For the purposes of communicating language semantics to programmers, it's generally acceptable.  Note that most popular imperative programming language reference manuals rely on English to describe the semantics of the language, with a few code examples (in the language being documented) to illustrate them.  The structures in Example 376 are those defined in TypeSystemCategoriesInImperativeLanguages.  The only thing done with those structures is what's described in TypeSystemCategoriesInImperativeLanguages.''

*** Switching between imperative-like pseudo-code and your other techniques makes it confusing. It's kind of like switching to a different author with a very different style in the middle of a book. To be thorough, it would be best to go further down the StepwiseRefinement tree instead of rely on a different presentation technique for the details.

*** ''It was a throw-away illustration in the middle of something else.  Some day, I might integrate it into TypeSystemCategoriesInImperativeLanguages, but I think my intended audience for TypeSystemCategoriesInImperativeLanguages -- the typical WardsWiki reader -- can get by without it.''

*** The audience for my model is regular developers, such that I use a communication technique that they have in common.

*** ''Your communication technique conveys incorrectness, particularly (but not limited to) your conflation of variables and values, which appears based on your conflation of a model of programming languages (in which values have no labels) with your application of that model (where values may have labels).''

*** You have not established that your version of "value" is clearly canonical. In fact, colloquial usage often contradicts it since things called "values" often don't carry type info "with" them. We've been over this already. '''There is no objective and clear measure of/from the I/O profile of our target languages that reveals the mandatory existence of your version of "value'.'''

*** ''True, values sometimes don't "carry" type info "with" them -- assuming by that you mean an implementation's "value" structure might not store a type reference adjacent to a representation in contiguous memory.  That's why I describe values as being a representation '''associated with''' a type.  That association '''always''' exists, even if it's implicit -- say, by choosing to use an assembly language's floating point "ADD" operator instead of its integer "ADD" operator -- but it's always there.  Without it, there's no way to know what type the representation belongs to.  As for an "I/O profile", program I/O is meaningless because it's arbitrary.  As soon as you include program source code in your "I/O profile", you're considering semantics and syntax.  Might as well just consider semantics and syntax.''

*** We've been over similar territory already in the "form field" discussion. Your "associated with type" was so very open ended such as to qualify just about anything under the sun. There's an "associated with" in my model's "value" also (at least for D1-like languages), such that it perfectly qualifies under "associated with". 

*** ''No, it only qualifies those values that have types associated with them.  Which, in practice '''is''' almost all of them.  Here's a representation with no type associated with it: 10101011101010101010101010111001010101111010101011010101010101010101110.  What does it represent?  Without knowing the type, it's just arbitrary bits.''

**** In the tag model, they DO have an association. If you want to qualify "associate" further, please do.

**** ''"Associate" needs no further qualification.  It is sufficient that it exists.''

**** Good, then it doesn't contradict the tag model's usage of "value".

**** ''Perhaps.  Where in the tag model is a type associated with a value?''

**** They belong to the same "record". That's a legitimate "association" by most accounts of the word.

**** ''That's good.  The problem is that you use the same "record" to model variables.''

**** Why is that a "problem"?

**** ''Because in popular imperative programming languages, values are immutable and anonymous, whilst variables are mutable and named.  Thus, they are mutually exclusive.''

**** Please clarify how they are "mutually exclusive". And values don't objectively exist in "popular imperative programming languages", at least not in a way that clearly and UNIQUELY matches your view of them. Thus, any characteristics you claim they have (they do this or that) is purely speculative or a UsefulLie. Don't make up "fake rules". Actually, the structures we both use are very similar, at least in non-stack models. The only notable difference is that I don't include the type indicator as a sub-component of "value". Further, being anonymous for external users (app programming & running) does not mean it has to be anonymous ''inside'' the model. Almost any interpreter emulator is going to need SOME way to reference/ID "values" inside, whether pointers or names. Inside the model, nothing is "anonymous". "Anonymous" is relative.

**** ''If you are modelling popular imperative programming languages, then values are immutable and anonymous whilst variables are mutable and named.  Something cannot be both immutable and mutable.  Something cannot be both named and anonymous.  Hence, values and variables are mutually exclusive.  If you are endeavouring to predict the I/O of popular imperative programming languages by creating an interpreter of your own, then you are not modelling popular imperative programming languages.  In that case, you can use anything you like for values and variables and whatnot and make it as complex as you like.  Of course, popular imperative programming languages have been around for a while, and have already provided us with the simple semantics that are documented at TypeSystemCategoriesInImperativeLanguages, so it seems rather peculiar to create an alternative.''

**** You are confusing the guts with external behavior (I/O profile), aka inside the black box versus outside. If you go deep enough into any guts or engine, everything is "mutable". The "internal variables" are NOT alterable NOR addressable from the outside (such as in the source code), and thus DO NOT VIOLATE I/O PROFILE MATCHING. Therefore, I don't know what you are actually complaining about, unless you are dictating arbitrary implementation specifics, which is a no-no for reasons already given. And TypeSystemCategoriesInImperativeLanguages is poorly written, as already described.

**** ''If your "I/O profile" includes source code as one of the 'I's, then it's no longer a black box.  It's true that at a machine level, everything is "mutable", but we're not talking about a machine level.  We're talking about the level of abstraction that your model represents.  At its level of abstraction, your values are mutable.  That is incorrect from a modelling point of view.  You may decide to do it for pragmatic reasons, but then you no longer have a model.  As for TypeSystemCategoriesInImperativeLanguages being poorly written, that may be the case.  However, given that you regard much of the written canon of ComputerScience as being badly written, I'm not sure your critique counts for much.''

***** Sorry, I'm not following. Perhaps an example would help. I mean source code of the "original" test case, not the modelling source. The modelling source may not even be written in the same language. The mutability/non-mutability profile matches that of "regular" code in the "regular" interpreter. A programmer using my model as an interpreter to run their app code (if completed to that level) CANNOT do extra "mutating" (changes). They can only do such if they "break into" the model and tweak the guts, which is true of the original production interpreter also. For example, if one fiddled with the source code of a Php interpreter or mucked with the machine code in the EXE of the interpreter. That's what I mean by "mutable inside only".

***** ''I don't know what you mean by "source code of the 'original' test case" as opposed to "the modelling source".  The rest, I'm afraid, I do not understand either; I think the context has been lost.  A value is never mutable, neither at a language level, nor inside its interpreter.''

***** Of course the "internal guts" of an interpreter are mutable, if one has access to the guts. Any byte in the interpreter EXE or stack is potentially alterable. Viruses do stuff like that all the time. And I've worked with debuggers that let one fiddle with various aspects of "internals" which would not otherwise be alterable via source code. Non-mutability generally happens at a higher level of abstraction. The tag model acting like a "regular interpreter" would NOT allow the altering of the intermediate values/variables or whatever one calls them. (The technique is explained in the "notes" section.)

***** ''Is your tag model an attempt to model interpreter internals?  Or is it a model of language behaviour?'' 

***** I don't see how this relates to the question. It's primarily a model of language behavior. But, since it uses a "toy" interpreter, or parts thereof, to serve it's (virtual) explanation, sometimes one wants to tinker with the guts to explore the toy interpreter.

***** ''A toy interpreter to tinker with interpreter internals sounds eminently reasonable, but then it's not a model.''

***** What exactly, in your words, is the difference?

***** ''A model is a replica of a system or object, resembling the system or object sufficiently to meet the stated goals of the model.  If you're modelling an interpreter to tinker with its parts, you can't call it a model of actual interpreters if some of the parts deviate significantly from actual interpreters.  Your value/variable conflation, for example, does not exist in real interpreters.''

***** It ''does'' meet the stated goals that I already gave. And according to your "deviate significantly" rule, a model of planet movement MUST use gravity itself. You seem to be making up rules again.

***** ''You've claimed it meets your stated goals, but have demonstrated no evidence beyond repeating your claim.''

***** I explained it as best I could and you had your chance to reply. Generally such has lead to an AnecdoteImpasse about typical developer WetWare. Neither side has an OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy to go beyond personal observation such that it's not worth complaining about lack of solid evidence for WetWare issues. But '''my model design choices ARE consistent with my stated goals and stated assumptions about typical developer WetWare.'''


**** ''As for values not objectively existing, we've covered that endlessly, but here's another piece of evidence that "my view" of types, values and variables is shared elsewhere: http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html''

**** That doesn't prove they exist. I agree "value" is sometimes a UsefulLie and I have no problem with UL's, but values don't objectively exist in the languages (per external behavior).

**** ''Values exist by virtue of VonNeumannArchitecture.  Every memory address or machine register holds a value.  That basic concept extends to its abstractions, like what variables store and what is returned by functions.''

**** Who says an interpreter has to run VonNeumannArchitecture? Besides, that's machine code level, not app language level. I meant "exist" in the language, not about existing in machines. Besides, bytes in RAM are more like variables than your version of "value": they are mutable and have an explicit ID, making them non-anonymous.

**** ''VonNeumannArchitecture is pretty much inevitable on VonNeumannArchitecture machines.  Of course, an interpreter could emulate an alternative architecture, but I know of no popular imperative programming language interpreter that does so.  Bytes in RAM are not like variables.  They are values.  The RAM addresses are like variables.  RAM can be considered an array indexed by memory address, or you can consider each memory location to be a variable where its address is its name.  At any given address, the value it stores is immutable.  To change the value stored at a given address, a new value replaces the old one.''

**** The last part of this baffles me. It sounds like an FP-philosophy viewpoint of the world, not something externally objective. Again, it appears as if you are mistaking your pet head notions for external truths. I know I keep saying that, but dammit, it very strongly appears to be the source of many problems here. I'll coin a new topic so I can reference instead of repeat: MentalModelOverExtrapolation.

**** ''I've simply described how machines work; nothing to do with "FP-philosophy" and everything to do with computer architecture.  On typical modern architectures, the values contained in memory addresses are atomically changed in 8, 16, 32, or (if supported) 64 bits at a time.  Some architectures support changing individual bits in an address, but any observing processes sees this as indistinguishable from changing the value stored at the address.'' 

**** I was talking about bytes, not bits. But even bits are still mutable, even if adjacent bits also get changed in the process. The arrow is bigger than the target, but the target is still successfully hit. "Mutability" is not about neighbors. Collateral damage doesn't de-hit the target.

**** ''Every machine RAM address can be assigned a value.  On machines with byte addressing, for example, every memory location can be assigned a value between 0 and 255.  However, each value is immutable.  We don't somehow mutate the 3 currently in address location 4023480293 into a 4, we simply store 4 in 4023480293.''

**** You seem to be dancing with words here, and stumbling in the process. Overwriting the prior contents is "mutable" in my book and I'm confident most programmers would agree.

**** ''Machine addresses, like variables, are mutable in that the current value can be replaced with a new value.  The value itself is not mutable.  There is nothing in any popular imperative programming language, or in any popular machine architecture, where a value 3 can change into a value 4.  In every case, an operator takes a value (say, 3) and returns a value (say, 4), or stores it in a register or an address.''

**** "Machine addresses" are mutable? I don't know what you are talking about. You seem to either see ghostly forces that I don't, or are torturing English in a way that would make even Cheney winch. And inside my model, my "values" (per my labeling) are no more mutable than yours are such that I am not in more of a violation of mutation laws than you are. You seem to be '''quibbling about obscure stuff''' anyhow with these nebulous mutability rules. My model satisfies the given I/O profile criteria. What the "values" or parts do inside the model is purely a personal choice not subject to some (imagined) universal law. '''Values don't have to exist to "run" an interpreter.'''

**** ''Machine addresses themselves aren't mutable, but the memory location denoted by the address is mutable: its value can be replaced with another value.  As for "values don't have to exist" to run an interpreter, I think you'll find if you build an interpreter employing the same semantics as popular imperative languages, that values do have to "exist".''

**** This is still confusing. Whether changed bits correspond to "values" or "value instances" or not is a vocabulary dance, probably a subjective one, but most people surveyed would likely agree that the "info in RAM is mutable" under typical scenarios, regardless of how YOU personally classify the info. And insert my usual reply about scientifically measuring semantics.

**** ''What's the difference between "values" and "value instances"?  Of course "info in RAM is mutable"; I never said it wasn't.  Please read what I've written, instead of what you'd like to think I'd have written.''

**** I've read it again and it still seems to be assuming unmeasurable ghost forces. Again, you seem to be extrapolating your person head models into universal existence or truths.

**** ''Sorry, I don't know what "assuming unmeasurable ghost forces" means.  VonNeumannArchitecture is simple stuff: Memory consists of 'n' sequential addresses, each of which can contain a value.  The value at any given address can be replaced with another value.''

***** There is nothing "replaced", at least not in the physical sense of the word "replaced". If something was physically replaced, then there would be an old version that had to be discarded or moved out of the way. Bits/bytes are "changed" is a more accurate description. I agree that one possible head model is "replace", but it's not the only valid head model, and is against the physical equivalent because no waste product is identified.

***** ''The terminology is irrelevant, but imagine that address 230983402 currently contains 4, then 3 is assigned to that address.  There is no observable transition phase in which the address partially contains 4 and partially 3, so it is perfectly reasonable to say that the 4 is replaced with 3.  Furthermore, there is no means by which 4 can be altered such that every instance of 4 is now 3, so it would not be reasonable to say that a value is mutable.  Only the contents of an address is mutable, solely by replacing one value with another.''

***** Physical replacement isn't instantaneous either in the physical world such that instantaneous-ness (or lack of observable transition) does not favor changing versus replacement. And I have no idea what the second part of that paragraph is about, unless you are going metaphysical on us. 

***** ''There are no metaphysics involved.  I'm simply pointing out that values are never observably altered.  There is no observable transition from a 3 to a 4, nor is there any case where a 3 is "turned into" a 4.  In every case, a 3 in a given slot is instantaneously (from the software's point of view) replaced with a 4.''

***** The '''content of the slot is mutable''' by normal English and human notions, whether we call that content "value" or "snoofnarg". You are playing word games here. Give it up, you are stretching English beyond ridiculous. You LOST this sub-debate as far as I'm concerned. I will not participate in your screwy word-play anymore. LetTheReaderDecide if you think you still have a shot.

***** ''Yes, the content of the slot is mutable, but the value stored in the slot is immutable.  Look at it like this:  Given a variable v used in the statements 'v = 3; v = 4;', is the value 3 changing into a 4?  Or is the content of the slot named 'v' being changed?''

***** Are we talking about abstract programming code, or physical hardware? I thought your argument was that the semantics mirror hardware, and the hardware is "immutable" and thus the "value" had to be immutable? "It's value" is an abstract idea in human heads, not a concrete objective thing. '''The contents of variables and RAM slots are mutable. Whether there is some middle-man thing called a "value" that is immutable is model-specific.''' There's nothing externally objective that says such a thing must exist. It again appears as if you are mistaking your personal head model for universal truths.

***** ''In terms of popular imperative programming languages, abstract programming code and physical hardware employ exactly the same model.  A value is stored in a slot.  The contents of the slot -- i.e., what value is in the slot at a given time -- is mutable.  What is stored in the slot at that given time, however, is immutable.  You do understand that an immutable thing can be stored in a mutable slot, yes?  Imagine, for example, a bucket.  A bucket can hold different stones at a different times.  Thus, the contents of the bucket are mutable.  However, the bucket cannot change -- it, like a machine address, is immutable -- nor can the stones change.  Each stone remains exactly the same, no matter where we put it or use it.  The only mutable thing is what stone is in the bucket at a given point in time.''

***** I'm not clear what specific parts of the bucket analogy map to parts of RAM chips and related processing. Please elaborate on parts mapping in the analogy. Note that as a working assumption, I agree that the "slot" specified by a RAM address is "immutable", but that's not an issue that I can see.

***** ''Bucket = memory address (or variable).  Stone = value.''

***** 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.''

****** Reply is at ValueExistenceProofThree. Topic maxed out.

***** Your assumptions about the WetWare and programming notions of the target audience are very different from my assumptions. Needless to say, we ran smack into the usual AnecdoteImpasse here. I do not believe that "value" is such a strong, clear, and solid notion in typical programmer heads such that it needs a "dedicated structure" or "locks" to avoid confusion. It adds an extra objective layer to the model that only appears to complicate it without clear and strong benefits to counter-weigh the cost of "extra code". You are welcome to build your own version of the tag model with explicit "value" structures and let the readers vote with their feet (mouse?) by using the one they like the most. Your ''One True Way'' campaign is unnecessary.

***** ''I have done so (though it's not a "tag model") in TypeSystemCategoriesInImperativeLanguages.  I suspect that those who find it difficult to grasp will find your tag model no easier, but I doubt such programmers will search out either description.  Weak programmers are weak particularly because they do little to help themselves understand programming any better.''

***** I believe "weak" versus "non-weak" is an over-simplification of individuals. If one encounters a model that closely fits their WetWare or preconceived notions, it may be much '''easier for them to digest'''. TypeSystemCategoriesInImperativeLanguages gives my WetWare constipation. Anyhow, let both models/techniques stand and LetTheReaderDecide. We just keep repeating the same points.

***** ''Precisely what makes a programmer weak is that he or she has confused WetWare and erroneous preconceived notions.  As a result, I doubt your notions will be any "easier for them to digest" than any others, and it's unlikely they'll seek out any better explanations.  If they were in the habit of looking for better explanations, they wouldn't be weak programmers.  Note that they may be strong in other areas -- office politics, for example -- so they're not necessarily weak in everything that is valuable to an employer.''

**** Continued at MentallyManageDynamicTypes

**** And re: (above) "There is nothing in any popular imperative programming language, or in any popular machine architecture, where a value 3 can change into a value 4." This is false, '''most regular programmers would agree this is an accurate or sufficient description''' of changing the "value" at a given memory address. It wouldn't be any different to saying one can "change the value at cell B3" in a spreadsheet. (Typically, it would be "change the cell at B3", but using "value" wouldn't raise an eyebrow.)

**** ''I don't know any "regular programmer" who thinks a 3 is mutated into a 4, and it doesn't matter what a "regular programmer" thinks, anyway.  Programmer (mis)perception is irrelevant.  A 3 is replaced with a 4, just as a 3 in cell B3 in a spreadsheet is replaced with a 4.  I don't know any spreadsheet program where a 3 is mutated into a 4.''

**** For one, regular programmers are the tag model's target audience, not PhD's. And see above near "ghost forces" about your apparent misuse of the term "replace". And you are wrong about regular programmers, who would agree that the ''slot'' at the memory addresses is mutable. I'd bet money that at least 75% would say "Yes" if you asked them if the slot referenced by a memory address in typical RAM is "mutable" (change-able), assuming they were familiar with machine language.

**** ''Of course the ''slot'' at a memory address is mutable, but the value that can be stored at that slot is immutable.  An address is mutable by virtue of the fact that the immutable value currently stored at a given address can be replaced with a different immutable value.  Values never change, only variables (and memory addresses are variables) change.''

**** The slot is there, most would agree, but a "value" separate from the "slot" is an invention of your mind. You seem to be picturing a kind of value sticker that is slapped into the slot. When the "value" is changed, the old sticker is removed and the new sticker placed on the slot. That's a valid mental model, but not unique and not ubiquitous. An equally valid mental model is horizontal wheel dials with digits on them (sort of like a thumb-enabled analog odometer). To change a slot's contents, one moves the dials. (If we assume a binary model, toggle switches will do.)

**** ''A value is what a slot -- i.e., a memory address -- contains.  That is how memory is defined in VonNeumannArchitecture.  I'm sure many analogies or human interpretations of this are possible, but they're irrelevant.''

**** Where exactly does the official Von Neumann definition say the slots are not mutable? You are making up rules again. The slot's contents are mutable, by common English descriptions. '''The slot's contents are as mutable as it can get''', short of explosions or melting of RAM.

***** ''Yes, the content of a slot is mutable, but the value stored in the slot is immutable.  Look at it like this:  Given a variable v used in the statements 'v = 3; v = 4;', is the value 3 changing into a 4?  Or is the content of the slot named 'v' being changed?''

***** See above, Repeat Boy.


*** And I've already mentioned that I include program source under the term "I/O profile" as a working definition. As defined, it's more objective/measurable than "semantics" such that I prefer to stick with "I/O profile" to avoid the messy/fuzzy notions associated with "semantics". 

*** ''When you "include program source", you are inherently including both syntax and semantics, otherwise it might as well be random characters.  "I/O profile" appears to have no definition at all, so I'm not sure how "includ[ing] program source" in "the term" contributes to its working definition.''

*** Somewhere I gave a fairly thorough description of "I/O profile". (I don't know if it qualifies as a "definition"). If I find it again, I'll link to it. "Semantics" is just too poorly defined to use in these type of discussions. And "random" is matter of perspective. 

*** ''Semantics is not poorly defined, just abstract.  "Abstract" is not equivalent to "poorly defined".''

*** Either way, there is '''no agreed-upon way to measure semantics''', such as verifying its existence or absence in a given thing, or testing/comparing for equivalency/similarity of one instance of semantics to another. Those are the basics of measuring.


** Also, if you '''watch kids evaluate expressions''' for math homework, you'll see different ways it can be done. Some draw little trees resembling an AbstractSyntaxTree; others reduce it one operand at a time, repeating the non-changed parts; some do the sub-parts at different parts of the paper and then put the mid-level results back together near the answer, etc. And one can even use a stack, like actual interpreters do. It's fairly clear they prefer a different way of organizing their computations, which probably reflects different thought processes. 

** ''Yes, different algorithms can be used to evaluate an expression.''

** How does one objectively know the students are thinking with "semantics" and not just using algorithms?

** ''I don't understand the question.''

* {When you write "only requires the I/O to match (including source code)", do you mean you are treating the source code as an opaque string, for which your only concern is whether or not one such string matches (or does not match) another?}

* For saying a model is "valid", yes. That's the most objective way I know of to say whether one interpreter/model is equivalent to another (ignoring machine performance and interpreter/model source grokkability for the movement.) I'll call this "I/O-equivalent" as a short-hand.

* {If the "source code" strings are opaque, how can you be modelling some aspect of them?}

* Please clarify. Where did I describe them as opaque? We are not modelling strings, we are modeling/recreating the transformation a given black box (the interpreter) does on them.

* {You agreed that they were opaque.  I asked, "When you write 'only requires the I/O to match (including source code)', do you mean you are treating the source code as an opaque string ...?"  You answered, "For saying a model is 'valid', yes."  Again, if "source code" strings are opaque, how can you be modelling some aspect of them?}

* It's a matter of scope. They are treated as opaque for evaluating whether a model passes the "match" test. But, they are not opaque for studying how a specific model works inside. All models probably have to process and dissect such a string, but there are multiple ways to do it, and thus "do" is not canonical from the implementation perspective (assuming we define "do" that way). The match qualifications do not require dissecting the source text, but it's an ''option'' legitimately available to a given model. In theory, we could construct a huge look-up table that maps the two inputs (data and source) to the output byte stream such that there is no need to parse: it's simple look-up. However, such table would have difficulty fitting in this universe. (In theory it would be infinite, but that's only if we assume the I/O can be of infinite size, which would fail existing interpreters because our computers have finite resources and addressing space. Thus, in practice the mega-map does not have to be infinite to be competitive with the existing ones.)

* {Sorry, you've lost me here.}

* I'm at a loss for a better wording at this point. I hope it's not an important issue.

Thus, even IF you pass the machine-existence hurdle, you still need to pass the sameness-measuring hurdle (equivalency?).

{What does that mean?  "Machine-existence hurdle"???}

You first need to demonstrate that semantics can exist in machines (interpreters). And then you need find a way to objectively compare two I/O-matching interpreters and say whether their semantics are the same or different. Thus, if semantics exist in software, how can we compare two instances of software to see if they have the same semantics?

{Without programming language semantics, all your interpreter can do is tell you whether the source code is valid syntax or not.  Semantics are what valid language statements do with the machine.}

That's called "algorithm", not "semantics". Anything at a higher abstraction than "algorithm" is in human heads and only human heads (barring an AI-based interpreter, which perhaps we can't rule out either). It's true that algorithms can be influenced by human semantics, but that's not the same as ''being'' semantics. Influence != Being.

{An "algorithm" is a specific arrangement of operations intended to perform a specific task.  "Semantics" are what the operations do, individually and/or as a whole.  A "sort" algorithm is the operations required to put a set of items in a specific order.  The semantics are "puts a set of items in a specific order."  Each operation within the algorithm has its own semantics, like ":=" in Pascal has the semantics "store the value on the right hand side in the variable on the left hand side."} 

To me, that's clearly the human head side of things. It's ridiculous to say that those concepts ARE IN the machine. Those concepts may shape/influence the algorithm, but that doesn't mean they are actually in the machine any more than "hunting" IS IN my cave sketch of a hunting scene. 

{It's ridiculous to say that those concepts ARE IN the machine?  Really?  A variable isn't in a machine?  There isn't a right-hand-side and a left-hand-side in a typical assignment statement?  We'd better tell the compiler/interpreter people about this; it appears they've been coding ghosts.}

It's a representation and/or projection of variables "in the machine". A painting of a hunting scene is not hunting itself. And the left-hand/right-hand thing is a syntax issue. We present ASCII bytes in a certain order by convention, and can use this convention to say a given symbol is "to the left" of another. We have syntax conventions that we can use to describe syntax, but I think most would agree that syntax is not semantics itself. (It's shaped by semantics, but influence is not equivalence.) It is generally acceptable in colloquial-land to say a variable is "inside the machine", but that's probably '''not suitable for rigorous analysis'''. When their OS crashes, people often say that "my PC is sad". But that's not intended to be a rigorous or objective statement. People use social and physical terms or analogies to describe equipment and virtual worlds at times, but it would be a mistake to take those literally.

{What is a "representation and/or projection of variables 'in the machine'"?  Presenting "ASCII bytes in a certain order by convention" is syntax.  What that syntax describes in terms of machine actions, are semantics.  "Variables" are defined by the semantics of a programming language.  Syntactically, there are no "variables", there are only identifiers (which are character sequences that follow certain rules), symbols, literals, keywords, and the various allowable arrangements of these.}

Re: '"Variables" are defined by the semantics of a programming language.' -- Where exactly? A syntax processor can distinguished between sub-classes of "identifiers", including "variables". The processor can usually say whether a certain byte in the source string belongs to a variable or a function name, etc. (I should point out that some interpreters delay making that distinction until it actually uses an identifier, but informally one can usually tell by reading the source code.) The "semantics of a programming language" is not an objectively observable thing. You might as well talk about unicorns and bigfoot: things we have yet to catch and study. Maybe you are religious and worship "semantic" spirits? Your descriptions are a lot like religious descriptions. Maybe if we approach them like a religion, this whole thing will start to make sense, or at least have a common reference point with something else we are familiar with. Otherwise, I'm a loss to do anything concrete with your claims. To me "semantics" are not a concrete thing, just human thoughts. Human thoughts cannot be measured or observed directly, but only by their impact on other things, and so far we have no universally accepted model of thoughts/ideas/notions by which to communicate about them effectively and rigorously.

{Semantics are described in language documentation and the code that implements compilers and interpreters.  That is objectively observable.  However, unlike syntax -- where we have semi-standardised notations like EBNF to describe it -- aside from formalisms like DenotationalSemantics and HoareLogic, we don't have standardised notations to express programming language semantics.  Nonetheless, semantics exist.  Note that "a syntax processor" as you've described it does not deal with notions of "variables" -- except to the extent that some syntax parsers do a certain amount of groundwork on behalf of the subsequent semantic processing, which only occurs once an AbstractSyntaxTree has been created.  A token like <variable> in a language grammar isn't recognised as a variable by the parser; its name is only for our benefit.  In most cases, <variable> in a grammar specification is merely a synonym for "identifier" (which is itself a synonym for the rules defining an allowable or valid sequence of characters) which only appears in certain places in the grammar.}

Language documentation is vague and overloaded when it comes to "types" and related. If there is no standard notation for language semantics, then it's very difficult to compare and contrast, including demonstrating universality or canonical-ness. It's almost like doing science before math. We need some kind of notation to demonstrate anything objective, or at least mutually agree about some characteristic of the thing being analyzed. I don't dispute that semantics exists, but there is no universally agreed representation for it. "Love" and "hate" and "sorrow" also exist (as ideas or notions in the mind), but we have no universal representation or notation for it to '''measure/prove exactly where it is and where it is not, nor equivalency; and thus are stuck with messy spoken language as a consolation prize.'''

{As I wrote, DenotationalSemantics and HoareLogic provide standard notation for language semantics.  Would you prefer that we continue this discussion using the DenotationalSemantics?  It might help to read  http://people.cis.ksu.edu/~schmidt/705s13/Lectures/chapter.pdf and http://users.encs.concordia.ca/~grogono/CourseNotes/COMP-7451-Notes.pdf first.}

* See PageAnchor Hoare_Horror and note the uniqueness requirement. And I'm not sure I agree the authors are actually representing semantics instead of algorithms. Calling it "semantics" does not automatically make it semantics. But first let's get the uniqueness proof.

* {There is no "uniqueness requirement".  That appears to be a misunderstanding of what "canonical" means.}

* Either universal uniqueness OR a common pattern identified among typical developers will do, as explained above. The second option is what I call "canonical". (Objective and clear pattern, that is.)

* {Sorry, I'm not following you.}

I'm not going to get into a definition fight over "variable". One can generally informally recognize one by looking at the source code (at least in terms of syntactical representation of one) and distinguish between function names, language keywords, etc. Now in dynamic languages sometimes names can be reused such that syntactical analysis may not be sufficient to classify accurately. But colloquially, one can identify most from the source patterns and peers will agree, at least if they know the purpose of the program and get hints from intent.

{In other words, you can recognise the semantics of a language by looking at its source code, because similar syntax invariably implies the same semantics?}

As already explained, different AI techniques can identify the same patterns, demonstrating that same output does not imply same processing. You have not demonstrated that all correctly matching outcomes proves a consistent semantics framework behind it. "Single path theory", I shall call it. Same-outcome != same-semantics.

{Can you demonstrate these "different AI techniques" creating an alternative but viable interpretation of programming language semantics?  It is certainly conceivable that alternative but viable interpretations of programming language semantics might exist.  I have never seen such, and even your model describes conventional semantics with added redundancy to (apparently) avoid "nesting" in your choice of notation.}

No, it's an analogy, not an implementation. I cannot X-ray human minds in sufficient detail and neither can you. What exactly is "redundant" about it? Maybe "analogy" is the wrong word. It's proof that matching I/O profiles does not automatically imply matching processing/thinking. (I consider neural nets "thinking".) It takes only one case to bust a rule that says matching I/O profiles always implies matching semantics (thinking). I/O profile matching may be considered weak evidence to back a particular case, but not sufficient by itself. It may be a prerequisite, but not a sufficient condition by itself to claim equal semantics.

{What's redundant about your model is that when your valvarueiables are used as values, the "name" attribute is redundant, and when your valvarueiables are used as variables, the "type" attribute is redundant unless you're describing Category S languages.  I have no idea what neural nets have to do with this, or why you consider them to be "thinking".  The rest continues to smack of conflating the semantics of human languages with the semantics of programming languages.} 

Sorry, I don't see redundancy. You'll need to be more specific on where exactly the duplication is. As far as neural nets, yes, I consider them to be "thinking". Oh shit, not a LaynesLaw mess over "think". Noooooooo! You guys are the ones using English to convey "semantics", not me. True, there may not be a lot of choice, but that's because semantics has yet to be scientifically tamed. That's not my fault. '''Until you capture bigfoot, few will or should believe you.'''

* {How many perceptrons are needed for a neural network to be considered to be "thinking"?}

* That is an excellent question. What exactly is "thinking"? Possibly related: WhatIsIntent.

[Formal semantics were "scientifically tamed" before you were born. It's your fault that you don't know this already.]

You haven't demonstrated uniqueness. The existence of an (alleged) semantic model is not proof of uniqueness.

{What is this "uniqueness" you're insisting on, and why?}

Search "prove equivalence".

---------
PageAnchor indirect_types

If all values must include a type component, then your model of variable and its parts in D2 language is wrong, because there is no "type" component for D2. If the type association is so strong in human notion-land (semantics?), then that notion would supersede languages categories.

''In category D2 languages, the type is the same for all values.  There's no need to put a reference to "string" in any value when a reference to "string" implicitly applies to every value.''

One could say the same for just about any casual usage of "value". It's basically a wiggle-room clause to make anything be or have a "type" when you need a type to exist for your pet definitions/models.

''You need a type to know what value a representation denotes.  For example, given a binary representation of 110110, what is the value?''

* Yes, but in dynamic systems, such is often tracked '''via convention or design assumption''', not explicit "type" indicators. Thus, a need for an explicit side component is not a necessity for being a called a "value". The assumption that something down the road knows how to interpret a series of bytes is a given, whether it be a machine or a human or both. But that down-the-road thing may be fairly remote so that it doesn't have to be kept WITH the "value". The tight coupling of your model is thus not tied to the actual rules or non-rules of value usage.

* ''That's why "is associated with" is so often used in this context.  An implementation may separate the representation from the type, chronologically or physically or both.  However, every value must consist of a representation associated with a type, otherwise -- as I've shown above -- there is no way to interpret the representation.  Again, given a binary representation of 110110, what is the value?  The obvious -- and inevitable -- question you must ask, before you can answer my question, is "what is its type?"''

* Okay, but it doesn't have to be part of a model because one may assume the app programmer or the reader or a distant machine will apply the correct "type" view.

* ''The fact that a value needs a type '''somewhere''' is sufficient to warrant its inclusion in a model.  Whether the type reference is distant or nearby (how near is "distant", and how far is "nearby"?) is irrelevant.''

* How does that follow? If it's up to a remote entity that is outside of our model's scope to determine "type", why does it have to be in the model? If it's up to the reader to "give meaning to" a set of bytes, does that mean we have to model the human reader? Good luck with that.

* ''I'm presuming you're modelling a programming language.  If you're modelling the transfer of an opaque data type -- like a BLOB in SQL terms -- from one system to another, that's something else entirely.  This has nothing to do with a human reader.''

* But in some cases, such as D2, the "types" are not part of the language itself, but rather part of the application code and/or the reader's head. Thus, the "type" falls out of the scope of what is being modeled. My original point is that a ''close association'' between "value" and "type" is not a necessity of "types" as used in the real world and colloquial-land. The association can be so remote that it stretches outside of the scope of something being modeled. Yes, in a specific language they may be closely associated, but that does not mean in general that a tight association is necessary. Developers and users often encounter "distant" associations of such, per form example. I'm talking about common usage of "values" here, not so much about interpreter modelling specifically. The output of the model may have to match the target language, but the internal guts of the model don't have to use the same type-related assumptions. '''Any type-related restrictions that apply to the target language don't necessarily apply to the internal guts of the model.''' For example, it's possible to emulate D1 languages using D2 languages.

* ''Types as "part of the reader's head" are irrelevant.  In D2 languages, values have a representation that belongs to a type (which is typically "string") that can encode values of other types as literals.  The literals are "parsed out" of those values' representations on an operator-by-operator basis.''

* But your type-attribute version of "value" (such as found in the D1 version) is not needed to model that. Thus, a '''close''' association of "type" with "value" is not a necessity in general and is thus not a '''universal''' characteristic of "value". 

* ''In D1 languages, a value is modelled as a representation-type pair where the type may vary.  In D2 languages, a value is modelled as a representation-type pair where the type is constant.  Hence, in D2 languages an effective shorthand is to model a value as just its representation, because it's recognised that the type is always, say, a string.  "Close" (or "far") is a qualitative judgement that is impossible to measure and generally meaningless -- different interpreters model the relationship between (say) a representation and a type in various ways, but they're all indubitably an association between a relationship and a type.''

* Ohhhh, so NOW you are permitting shortcuts and factoring to legitimately exist. Gee, I wonder what else we can simplify for particular models. Hmmm, let's see what might have unnecessary nesting....

* ''That has always existed in the description at the top of TypeSystemCategoriesInImperativeLanguages.  See "Language Category D2" | "Illustration".''

* So I likewise have the "shortcut" of factoring your "value" and "variable" together to avoid a nested structure because it's the primary structure used by the model user and "values" of your style are rarely if ever used in the model.

* ''However, a problem with your "shortcut" is that "factoring 'value' and 'variable' together" conflates them.  How will that help the struggling programmers for which your model is intended?  Do we really need weak programmers believing that functions return variables, and other nonsense?''

* It's not fucking "nonsense"; YOUR canonical claims are nonsense because you have no rigorous proof of it, only vague hand-wavy repetitious English. "Values" may be a UsefulLie in some cases, but they are '''not required to exist''' to produce a matching I/O profile. (I suppose if a definition of "value" is made wide enough, then one can force its existence using word-play.)

* ''You don't think functions returning variables is nonsense?  (Actually, it isn't ''strictly'' nonsense, because it is possible to have functions return references to variables, but a "variable reference" is a value not a variable.) In the context of popular imperative programming languages it's nonsense, because no popular imperative programming languages have functions that return variables.  If they did, you'd be able to do this: "foo() = a + 3", i.e., assign the result of adding the value in 'a' and 3 to the variable returned by invoking function 'foo', or whatever.''

* Your sample expression is probably a syntax error in the target languages. It can't happen (won't run) such that it's a non-issue; a test that proves nothing. (If you find a case where it works, let me know.) As far as "functions return references to variables", that can be modeled as putting the address of the target variable instance in the "primary" variable, which would be '''just like receiving an integer''' from the function. The indirection is processed/applied by whatever uses that variable/thing/object later on. It's not really different from your approach, except my version of your "value" has an extra attribute that allows it to be addressed (internally) like a variable. That extra attribute doesn't kill puppies. It's a '''super-set''' of your structure such that it can do at least the same thing and process such address indirection probably the same way you would. (I say "probably" because I'm not clear on some of the details of your model.)

* ''Of course it's a syntax error.  I wrote, "'''if they did [support functions that return variables]''', you'd be able to do this: "foo() = a + 3", i.e., assign the result of adding the value in 'a' and 3 to the variable returned by invoking function 'foo', or whatever."  They don't, so you can't.  Of course your "extra attribute doesn't kill puppies", but it's awkward and needlessly complex.''

* I'm not following what you are getting at. You are inventing features out of the blue. Functions returning variables automatically implies they should also accept "results" of expressions? How does that logically follow? A generator of something doesn't automatically have to be a taker also. My reply to the rest would resemble PageAnchor tradeoff_rant_48. "Awkward and needlessly complex" appears to be a subjective evaluation.

* [Because one property that variables have is that they can be assigned to.]

* Functions generating variables is NOT the same as BEING variables.

* [You said that the function "returns" a variable, if it returns a variable, then what it returns IS a variable. Anyway, if the function generates a variable instead of returning it, what role is the variable playing in "foo() = a + 3", and what is the function "foo()" returning?]

* I'm sorry, I don't know what you are talking about. It appears disjointed. You lost me, dude. "foo() = a + 3" is a syntax error, per above. It's invalid JavaScript and it's invalid in Tag Model (unless we explicitly add it for a particular language that does recognize such).

* [There are two things. The first is, up until two responses ago, you said functions returned variables. If functions return variables, then the thing returned is a variable. Therefore, "foo() = a + 3" isn't a syntax error, since the left hand side, being a variable, can be assigned to. The other thing is a question, asking you what you mean by "Functions generating variables is NOT the same as BEING variables". I, in particular, want to know what role the variable is playing, since  you seem to be denying that it's returned by the function, and what is being returned.]

* Okay, I think I now see what you are getting at. "foo() = a + 3" can be viewed as equivalent to "t=foo();t=a+3;" '''inside''' the model. That may be true, but the first version is still a syntax error for EXTERNAL code and thus could not happen in actual source. Yes, we can fiddle with the internals in ways the black box user couldn't. But that does not violate the matching criteria for models since we are not measuring fiddle-ability of internals by those can get at the guts of a particular model. You are only demonstrating ways to "tweak the guts". Is this a model user-access security question? (The model does not explicitly model the parsing step at this stage in order to keep it simple and focused. But the syntax processing stage is where such syntax errors would be normally be caught.)

* {No, if foo() returns a variable, we could assign to it because variables allow assignment, so "foo() = a + 3" would be valid in languages where foo() returns a variable.  It's not valid because foo() doesn't return a variable, it returns a value.  We can't assign to values.  The syntax checking in popular imperative programming languages merely reflects these semantics because it's convenient to eliminate such errors syntactically.  Using conventional semantics, "t=foo();t=a+3;" merely states that the value returned by foo() is assigned to 't', and then the value resulting from evaluating the expression 'a + 3' is assigned to 't'.}

* If my model reflects the I/O behavior of the target language/interpreter, including rejecting certain statements, it has '''done it's job'''. You are dictating implementation rules now. Micromanaging.

* {How am I "dictating implementation rules now"?}

* Error message note: I suppose one could claim error message text should be part of the "matching criteria", but generally they are not. If vender A's interpreter for Footran gives somewhat different error messages from vendor B's interpreter for Footran, generally that's not sufficient to disqualify equivalency. Now, one not flagging while the other does flag may be of concern. Anyhow, syntax error detection is outside of the scope of my model, regardless. I've seen cases where one version of an interpreter flags a pattern during runtime, while a future version flags it during "compiling" or parsing. But most don't use that as disqualification either. (Most error messages from the common languages are very crappy, I would note, probably reflecting internal guts out of laziness or speed/size tradeoffs.)

* {What does this have to do with the above?}

* Arrrg. From an I/O standpoint, what specifically is "wrong" with my model? Otherwise, I don't know what your objective complaint is. You appear to be complaining about implementation, which is moot for our purposes. If fully implemented, "foo() = a + 3" is invalid in my model just like the reference interpreter. That should be end-of-story. 

* {Given that your model appears to be a poor (i.e., odd terminology and conflated values and variables) model of the semantics of popular imperative programming languages, regardless of its intended "I/O only" purpose, and given that the semantics of popular imperative programming languages are simple, it seems your model is redundant and -- because of the odd terminology and conflated values and variables -- bound to cause confusion amongst precisely the audience for which it is intended.  By the way, what in your model prevents "foo() = a + 3" from working?  Your model treats values and variables as the same, so why shouldn't we be able to assign the result of an expression to the result of a function invocation?}

* For the record, I disagree with your claim that it differs from an alleged canonical "semantics" in programmer heads, but we have other sub-threads on that fight (and I am disturbed by your heavy repetition of the complaint).  As far as "redundant", I'm still not clear on where the redundancy is. And the last question was already answered: it would be a syntax error. (I'm not adding an explicit syntax-checking module because it's outside the intended usage of the model and would bloat it up, but others can add such if they want.)

* {"Programmer heads" are irrelevant.  Your model differs from language semantics; it doesn't matter whether or not it differs from some human interpretation of said semantics.  Why should "foo() = a + 3" be a syntax error?  If foo() returns a variable, why shouldn't we be able to assign the result of "a + 3" to it?  Of course, since "a + 3" evaluates to a variable, we should be able to assign to it, too.  Shouldn't "a + 3 = foo()" also be legal in your model?  If not, why not?}

* By way, if I do that in JavaScript, I get "Cannot assign to a function result". It calls it a "result", NOT a "value".

* {Of course -- "result" is a common shorthand for "resulting value".}

* So you claim.

* {It's true.  If you believe otherwise, please demonstrate a function where its "result" is not a value.}

* I don't have a clear enough definition of "value" to apply that test. Further, "value" is overloaded such that it CAN mean what you want and it CAN mean what I want.

* {Can you give a "clear enough" definition of what a function returns?}

* I don't want to define stuff if I don't have to. Based on past experience, I should try to avoid attempting rigorous IT definitions. It seems we can only say concrete things about explicit implementations, not general concepts. But I will say that in D1 languages, functions return at least a type indicator of some kind, and a value/literal/data-item-like thingy. The packaging of these two concepts differs per model, and as long as these two things are "kept" for a while in some manner and are accessible to the model's guts, the models have sufficient info to "do their job".

* Discussion continued at MathAndObjectiveExistence.

Plus, I can use your own wiggle weapon against you and say my usage of "value" has an implied type of "string".

''In that case, you're only modelling D2 languages.''

In my model's case, we are talking about the parts INSIDE the model, not the language being modeled. Different scopes. 

And that doesn't matter anyhow if you are talking about UNIVERSAL definitions. If it varies per "language type", then it's not a universal rule, but rather a situational rule. 

And most programmers (and form users) barely notice a difference between D1 and D2 in practice such that it's not going to significantly shape their vocabulary interpretations. I suspect you may argue professional interpreter writers care about such subtlety, but PIW's are NOT the target audience.

''I don't see how that addresses my point.''

Let's see if I can restate this. My model tends to use D2 conventions ''internally'' (to keep things clear), but it can model D1 languages themselves. Thus, am not modelling only D2 languages, as you appear to claim.

''If your values don't have explicit type references, you're modelling D2 languages and not modelling D1 languages, whether that's what you intend or not.''

Wrong. That value thing is your specific model's requirement.

''It's more than that:  It's a programming language requirement.  I simply document it.''

Wrong.

''What does a function return?  What does a variable store?  What does an expression evaluate to?  If your answer is anything other than "value", you're wrong.''

They DO return "values" in my model, but they also return other things. Also, I don't necessarily claim such statements are a universal truth; they could be model-specific. Without an established and clear definition, it's hard to say.

''I don't claim such statements are a universal truth either.  Note how I've always been careful to use the phrase "in popular imperative programming languages" because in those, functions always return values, variables always store values, and expressions always evaluate to values.  I don't know of any imperative programming languages (popular or otherwise) that don't embody this, but if you feel "popular imperative programming languages" is too vague, think of it as being the top 15 programming languages on the TiobeIndex as of November 2013.''

Even in the top dynamic languages, "value" is not objectively and clearly defined. Source code has no direct "values" (per syntax diagrams etc.), and so if they exist, they are either internal to the implementation (which is somewhat arbitrary), or an abstract idea in human heads.

''Remember, every language requires both syntax and semantics.  Without both, there is no language.  "Values" may not have specific syntactic elements (though literals denote values), but they have specific semantic elements.''

I would test that claim, but I cannot find where the "semantics" are to yank them out and watch it "run" without them. That's not sarcasm either: one of the best tests for the claim "X requires Y to work" is to yank out the Y and see if it stops working.

''This can be done trivially.  Download the RelProject, install the source code under Eclipse and verify that it runs by launching Rel3DBrowser:DBrowserWithoutMonitor.  Then go into each of the low-level virtual machine operators in Rel3Server:ca.mb.armchair.rel3.vm.instructions.* and replace the current definition of "execute(Context context) with "public final void execute(Context context) {}".  That eliminates the semantics by turning every language statement into "NoOp".  Run it and see what happens.  Hint: When you run scripts, no databases will get updated, no files will be opened and read or written, no output will be produced, nothing will happen.  Programs will be recognised as syntactically valid (or not), but they won't '''do''' anything.''

You are yanking out the algorithms, not semantics. We already agree they need algorithms to work. Your arrow is bigger than the target. Can you leave the algorithms in and yank out the semantics separately? (And I won't let you trick me into installing RelProject. Nice try.)

''Algorithms are used to implement language semantics.  In the RelProject, algorithms implement the TutorialDee language semantics.  By "yanking out the algorithms" that implement the semantics, we remove the semantics.  The language semantics are reflected in the interpreter code by the names of the machine instructions, e.g., O''''''pAdd, O''''''pRestrict, O''''''pJump, O''''''pConcatenate, and so on.  The semantics of O''''''pAdd or "+", for example, is "numeric addition on integer values" in English (that's what it means to us) and it's implemented in the "O''''''pAdd" class of the ca.mb.armchair.rel3.vm.instructions.core package by the following (simplified, for illustration) algorithm: "v1 ← pop(); v2 ← pop(); v3 ← do_integer_addition(v1, v2); push(v3));"  That algorithm is what "+" "means" (I'm using a deliberate anthropomorphic term here) to the machine.''

I thought "semantics" were at a higher abstraction level than PUSH, POP, and JUMP instructions. That's arbitrary (non-unique) implementation detail. Let me put it this way; the kind of semantics were are interested in for ''this'' topic are those that typical programmers share and use, not chip-level issues. Let's not drag chips into this if we don't have to, it's messy enough as is. And why do you have to deliberately anthropomorphize it? Perhaps because (non-AI) machines don't have notions and ideas? And if they did, how do we measure it, such as detecting its presence or absence or equivalence?

''Semantics are independent of the abstraction level.  Semantics describe "what"; algorithms describe "how".''

We've been over this already, "What" is vague in this context.

''In this particular context, I've been deliberately vague.  In the context of actual language statements, it's not vague at all.  "while (p) {}" is a loop.  That's "what" it is; there's nothing vague about that.  "How" involves details of the mechanisms of expression evaluation, branching, etc.''

"Is" implies some kind of equivalency, or at least membership to a designated class/category/type. What objective equivalency/membership-verification device are you employing here?

[Looking at the language definitions, of course. Can you find a popular language where "while (p) {}" isn't a loop? I tried to and couldn't.]

If one builds a regex-like tool to classify such syntax patterns as "loops", does that mean it's using the "same semantics" as programmer heads (or your head)?

{I don't understand the question.  What does "programmer heads" have to do with programming language semantics?}

What is performing your "isn't a loop" test above?

{I'd expect it to be the test code that verifies whether or not the code inside '{}' is repeated as long as 'p' is true, but you can also examine the language documentation or the source code for the interpreter or compiler to see what it's meant to do.}

An objective loop detector algorithm? That'd be cool if you can pull it off without relying on syntax. But if we are talking about "typical Algol-style languages", then syntax is probably sufficient, and humans can also use such "historical" syntax patterns to say "yes, it's a loop". They don't necessarily need higher-level thinking to pull it off. In other words, certain syntax patterns are usually associated with loops out of tradition and convention. To "fail" your test above, somebody would have to decide to violate convention. There is no rational purpose to do such, other than jack around with people or hide something.

{It's not a loop detector, but simple code -- written in the language under test -- to verify whether it's looping or not.  The only reason "typical Algol-style languages" are "typical" is because they share both common syntax '''and''' common semantics.  If they shared only common syntax, we'd be talking about how exactly the same statements do completely different things.  We'd be asking why "a = foo() + b" assigns the result of invoking 'foo' plus 'b' to 'a' in C#, but rotates object 'a' about the 'foo' axis by 'b' degrees in <hypothetical but imaginary popular imperative programming language 'x'>.  Therefore, the convention to which you refer is both syntactic '''and''' semantic.}

But this "semantics" is a notion-y human head thing. It's not an objectively dissect-able entity. There are also processing algorithms/rules that are typically associated with such syntax patterns. But to call that "semantics" may be a reach. It could be merely tradition/habit. A tool is built that way because somebody started building it that way in the past and people liked it enough to keep using the same syntax-to-algorithm patterns. It's an association between syntax patterns and processing algorithms that humans either like or live with due to comfort or something else. '''To say it "means" something may be giving it too much credit.''' It may merely be a useful association habit. To say it "means" moving foo to bar or whatever may not be necessary or accurate: people see the pattern and associate a reaction based on that pattern and past experience. It does not mean they are translating it into a clear set of steps or higher-level meaning any more than we recognize a cat when we see a cat even though we are at a loss to precisely and completely describe how we mentally do that and tell it apart from possums or mountain lions.

{No, you're insisting that "semantics" is a notion-y head thing.  Semantics defines, for example, that a variable is a language construct that can be assigned values and that has a name.  A programmer implements the semantics of variables in code by constructing mechanisms (using algorithms, yes) to assign values to variables, retrieve values from variables, and give variables names, and then associates aspects of those mechanisms with language syntax.}

Like I said, human mental semantics SHAPES such algorithms, but that is not the same as semantics "being in" the interpreter. Influence != Equivalence. And I don't see how your (non-unique) English version of an assignment statements supports your claim. You keep giving those English snippets, as if repetition will convince me. To me it's just a lossy translation of your '''personal''' pet head model into English.  That's all; nothing more. -t

{Would you prefer that I used some formal notation instead of English?  A formal notation would eliminate possible ambiguity, but for informal discussions -- as opposed to mathematical reasoning -- English is generally friendlier.  Semantics are "in" the interpreter; there is invariably (out of necessity -- semantics become code in real interpreters and compilers) a correspondence between semantics and the code that implements them.  My English version of an assignment statement is the only way assignment is defined in every popular imperative programming language.  If you disagree, please provide a counter-example.}

I did provide counter examples already. You ignored them, multiple times. Your English version is not the only way to describe such. If you mean it's the only way "defined", then show where this canonical definition is, beyond anecdotes. And if you use a formal notation, you will need to demonstrate it's truly capturing "semantics" and not something else (such as an algorithm or observations about an algorithm).

{What "counter examples" did you provide to show that there are different interpretations of assignment?  In particular, how do they contradict my descriptions?}

* The ones where I showed that the word "value" was not needed. And I never claimed they "contradicted" your descriptions. Having more than one way to say or model something does not by itself create a contradiction.

* {Omitting some detail does not mean they have different semantics.  In "a = foo() + b", we can say the value returned by the invocation of foo() is added to the value in variable 'b' and the resulting value stored in variable 'a'.  Or, we can say 'foo' plus 'b' is assigned to 'a'.  The semantics are the same.  They differ only in detail of description.  Different semantics would be something like "a = foo() + b" means rotate object 'a' about the axis labelled 'foo' by 'b' degrees.}

* It's not "omitting details", it's not filling in blanks with '''arbitrary''' or model-specific terms. One can get away from model-specific terms by using pronouns or the like: "The variable stores the stuff generated by an expression". There is no universal rule that says we MUST call that stuff "value". (I like "stuff" over "thing" or "object" because we don't have to specify whether it's singular or plural. In my model the "stuff" is plural.)

* {There's no reason to use a vague and colloquial term like "stuff" when the conventional term for the concept we're discussing is "value".  It's true that there's no universal rule that says we MUST call it a "value", but it's usually called a "value", so "value" is what I call it.}

** I would agree, but when making a more rigorous model, the fact that its overloaded can create problems and another word may be needed, as already described many times. (You should have anticipated that if you had a decent or unbiased memory.) "Value" would be a better word for you "representation" also, but you "spent" that money on something else. Tradeoffs.

** {There's no "tradeoff" here.  Dealing with an "overloaded" term is trivial: simply make it clear what definition is being used.}

** If an explanation can be considered sufficient to "fix" awkward areas, why are you complaining about my "value" usage or non-usage? It smells like a double standard.

** {I have no objection to clearly-defined terms used according to convention, and/or in technically-correct fashion.  I object to the fact that you use overloaded terminology -- like "tag" and "anonymous constant" and "hidden variable" -- without any definition and in ways that do not accord with the usual applications of these relatively familiar phrases.  And I object to your conflation of values and variables.}

** "Value" is overloaded, as are a good many terms colloquially used to describe code and programming. And almost any model is going to have model-specific parts with model-specific names (such as "D2"). I agree I have been sloppy/inconsistent with some of the internal names, partly because I haven't decided on the best words to use yet. 

* And the "rotate" kind of approach may work for somebody who '''thinks mechanically'''. Maybe Charles Babbage thought of assignments in a kind of mechanical way: gears, sprockets, pegs, etc. bumping, pushing, and influencing each other. '''It's a valid model''', I won't penalize him. (It's not well-suited for today's equipment, but no model will fit every era's equipment well.) -t

* {I think you may have misunderstood the example.  "Rotate" is not meant to be some alternative interpretation of assignment.  The "'a = foo() + b' means rotate object 'a' about the axis labelled 'foo' by 'b' degrees" example is intended to illustrate semantics in which 'a' isn't a variable, '=' isn't assignment, 'foo()' isn't a function invocation, and '+' isn't addition.  In other words, it's semantically different from our usual interpretation of the "a = foo() + b;" syntax.}

* This gets back into the problem with the word "is". One can use a mechanical model of a variable in their head and successfully reason and process such statements just like one use to the school-paper version. Who is to say their mechanical version of "variable" is "wrong"? If they describe that assignment, they may say something like, "rotate sprocket to position "a", triggering the peg matcher, which makes the latch drop when the accumulator is finished...". If you want to say the semantics are still equivalent, you need to describe specifically HOW one tells they are equivalent.

* {I think you're still misunderstanding the example.  "Rotate" is not meant to represent "a mechanical model of a variable".  It's not assignment at all.  It has nothing to do with assignment.  The 'a' in 'a = foo() + b' isn't a variable, it's something else, and '=' isn't assignment, etc.  The only thing 'a = foo() + b' has in common with its equivalent in, say, C# or Java is that it has the same syntax as "assign the result of adding foo and b to a", but it is something else entirely.}

** I am saying that one could use a mechanical view, regardless of what you intended to mean. Is a mechanical view still the same "semantics"? If so, how does one tell? It's back to the problem of measuring and comparing "semantics". It's something that has not been scientifically isolated so far.

** {Semantics are defined and documented; how they're inferred is immaterial.  Some nuanced misinterpretation of programming language semantics is irrelevant, in the same manner that some misunderstanding of science -- say, thinking that meteorites are pieces of the moon hurled by angry space gods -- is irrelevant to our scientific understanding of cosmology.}

** This is not clear to me. And I am not talking about "misinterpretation". A mechanical view is not necessarily "misinterpretation". Put another way, one can look at a math expression, and think of the evaluation process/steps/meaning in mechanical terms, after spending a good while with machinery (or having a natural affinity to it).

** {In short, human interpretation of language semantics doesn't matter.  Semantics are defined and documented by the language designer, and implemented by a language implementation.  Anything outside of that is irrelevant.}

** Like I've said before, the language designers are often poor documenters. Fortunately, the target languages tend to ''behave'' similarly such that experience can often compensate for poor written documentation.

** {That languages behave similarly is a reflection of their common semantics.}

** "Reflection" as in "influenced"? That I don't dispute. But not proof of equivalency or similarity of semantics.

** {Semantics are more than an influence.  Semantics, along with syntax, are what define a language.  The fact that a given program, with only minor syntax tweaks, will run equivalently in all popular imperative programming languages is proof that they have the same semantics.  If they had different semantics, the program wouldn't run equivalently in different languages.}

** So you claim.

* {Semantics can be easily determined to be equivalent across multiple languages by using the semantics -- as understood by the programmer -- to build programs that he/she believes to be equivalent.  Then run them to see if they are equivalent.}

* It could be mere algorithm translation, not semantics translation, although without a clear way to measure and isolate "semantics", it's hard to know.

* {Programming language semantics are what the parts of a programming language mean, not what programs written in the language mean.  "Algorithm translation" is irrelevant.  Any program or portion thereof, regardless of purpose, can be used to test semantics of a programming language.}

* How about a clear example of this "testing semantics".

* {Sure.  If the semantics state that, for example, "a = 3 + 4;" means "the value resulting from evaluating the expression '3 + 4' is assigned to a", we can verify the behaviour defined by the semantics by writing, say (in Javascript), "var a; alert(a == 3 + 4); a = 3 + 4; alert(a == 3 + 4);" We'd expect it to pop up "false", then "true".  Of course, this presumes we've done some tests to verify the semantics of '==', '+', 'var', and 'alert' beforehand, or that we have reason to trust that they behave as documented.}

* Arrrrg. Again, interpreters don't process English. Your example is silly and useless. You appear to be anthropomorphizing interpreters.

* {Where do you see something processing English?  The English is the terminology and descriptions we use to describe semantics.  The only "processing" I see is that source code, run through an interpreter, demonstrates conformance with an English description of its semantics.}

* Your "means" is defined in English. If that's not what it's processing, then all you have is a lossy personal interpretation of...something. What is the purpose of your English "means" phrase? If it has no purpose in that paragraph, then don't put it in; it's distracting.

* {"Means" is defined in English, because source code is meaningful to humans.  When we write an interpreter or compiler, we make source code "meaningful" to machines.  It doesn't matter that the former involves cognitive neural WetWare and the latter involves mechanistic, deterministic, computational HardWare, because as computer scientists and SoftwareEngineers the relationship between source code, the machine, and our understanding is a well-known one.  It is, after all, why we almost exclusively program computers using languages instead of hardware switches.}

* It's a bit of a stretch to use "means" for machines. True, people often anthropomorphize machines, such as "the vending machine didn't like my dollar bill", but that's either a misuse of such terms, or doesn't say anything specific. "Semantics" is not directly measurable, but "behavior" is such that it's better to talk about "similar behavior" rather than inject "meaning" into machines. I believe you to be making a similar mistake as the person talking about the vending machine.

* {If you don't like "means", it is fine to say that semantics describe what a language is, and what it does -- in terms of language components -- when it is executed.}

* To me, "what a language is, and what it does" is defined and qualified by the I/O profile (already described). That is clear and objective (at least more-so). (True, it's difficult to qualify with 100% certainty, but that's very common in science models.)

* {How does the "I/O profile" distinguish between a program that prints the first ten prime numbers by calculating them, versus printing the first ten prime numbers using ten 'writeln' statements?}

* See Example loopy-72. That's only one specific test case, not enough to fully test a model/interpreter. The "profile" is not based one test sample. In practice, both programs would satisfy the user equally for that particular need.

* {How many specific test cases are enough to "fully test a model/interpreter"?  What if the prime number output program is parameterised, and cheats by printing predetermined primes less than 'n'.  How do you discover 'n'?}

* The only way to know that just about ANY interpreter is bug-free is to test every possible case.  Obviously, that's not practical, and most interpreters probably have bugs. 

* {So how many test cases are enough?} 

* I know you are going to hate this response, but that's an '''economics question''': How much resources/effort do you wish to spend to ensure the tool is sufficiently good enough for its intended use or fits expected behavior. -t

* {I don't hate the response, I just find it peculiar.  It implies ignoring the semantics of a language purely in favour of examining the I/O of test programs.  Do you not intend to test individual language statements?}

* I "ignore" them because they are not scientifically measurable/measured so far. And of course one tests individual statements. TypeTagDifferenceDiscussion gives examples you've probably seen already. Generally one WANTS to test individual statements, it makes most empirical analyses easier.

* {Ignoring semantics because they "are not scientifically measurable/measured" is peculiar; it dispenses with a fundamental -- and mathematically rigorous -- component of programming languages in favour of what appears to be a portion of natural science.  I don't think "linear algebra" or "trigonometry" can be "scientifically measurable/measured" in the manner you suggest either, and yet they're as fundamental to computer graphics as semantics are to programming languages.  Shall we ignore linear algebra and trigonometry, too?}

* If you view trig as a tool, then you can test it as a tool. If you represent it in a specific notation, you can say things about it in terms of that notation. Nothing similar has been done with "semantics" yet.

* {Actually, something exactly the same has been done with "semantics":  It is no less than the "specific notation" of a programming language -- with which you can say things about the semantics in terms of the language's notation -- and every interpreter or compiler that implements it, which allows you to verify the things that you can say using the language's notation.}

* One can analyze syntax, yes, but that does not by itself mean one is also analyzing semantics in the process. "Meaning" is in human minds and has not been scientifically tamed to any detail. That's the bottom line.

* {Analysing syntax only reveals that symbols can only be arranged in certain ways.  What those arrangements cause in terms of run-time computation, is what semantics represents from an interpreter or compiler point of view.  The "meaning" in human minds is irrelevant.}

* You again appear to be anthropomorphizing machines. They don't have a "point of view". Interpreters are just dumb "savants" that follow specific instructions for changing RAM. There may be common pattern(s) to the I/O profile of language interpreters for the target language set, but that pattern is not necessarily "semantics", as I interpret the word (and probably many others). I'm tired of arguing over vocabulary. Unless you can scientifically tame and measure your version of "semantics", it's just a vague battle with vague casualties that won't go anywhere.

* {Fine.  What syntax arrangements cause, in terms of run-time computation, is what semantics represent in interpreter or compiler.  Read any language manual -- the parts that aren't syntax or language history or design philosophy are describing semantics.  Most language manuals are mostly about language semantics.}

* Such descriptions are full of UsefulLie''''''s, analogies, and vague notion-y English. It's not rigorous nor meant for rigor. The little example snippets are the most important parts of such manuals to most programmers. Essentially, it's learning-by-example (mini I/O profile patterns). If the written part of such manuals are "semantics", then it's casual, overloaded, and inconsistent semantics; too rough for our needs here unless both sides accept ambiguity and plurality of valid interpretations.

* {I see.  So you'd prefer formal descriptions of semantics?  Sounds good to me.  See page 32 of http://www.haskell.org/definition/haskell2010.pdf for an example of formal semantics for case expressions.  Do you think most programmers would prefer that over English?}

* I didn't say that. Examples and experimentation is a perfectly good way to learn. English is poorly suited for describing virtual cyber-worlds not tied to physics, but so far the best competitor is to show instead of tell, for most humans.

* {So you suggest programming language reference manuals should consist entirely of examples, without accompanying English text?}

* That's an interesting question, I've never explored it at the extreme end. English is fine for giving general descriptions and providing general notions or analogies as a supplement to and labeling of examples. 

* {I think it would only work if a pre-understanding of language semantics is assumed.  Otherwise, the examples would be meaningless.}

* I'm not sure what you mean, but we already know we have different assumptions about programmer WetWare.

* {What I mean is that I suspect a language manual that consists entirely of code, sans English descriptions of what the code does, would be meaningless unless you already have knowledge of almost the same syntax and the same semantics.}

* It is true that different explanation "angles" often explain things better than a single angle alone. Sometimes this is called "mental triangulation". By itself, English is a poor tool.

* {Sure, but that doesn't address my point.  What I'm saying is that a description of language semantics must necessarily rely on English, or some other recognised notation.  It is not sufficient to describe the semantics of a language using only the language itself.}

* I don't know if that's true. A non-English speaker new to programming who studies code snippets may be able to figure out "how" it works.


{Algorithms that implement a language aren't visible in a language, so we can't capture those or observe their behaviour except as behaviour in the language itself.  Therefore, if we're not capturing syntax, we must be capturing semantics, because a language is defined by its syntax and semantics.  There isn't anything else.}

But you could be creating an alternative algorithm or portions of an algorithm, but calling it "semantics". You don't have to see the original (implementation) algorithm to make such a mistake.

{I don't follow you.  Could you give an example?}

Dr. Fobiz could create a notation that he/she claims represent "semantics". But really it's just another way to define algorithms (of say an interpreter), or parts of algorithms. How does one know if such a notation is actually representing "semantics"? We shouldn't just take Dr. Fobiz's word for it.

{If defining algorithms or parts of algorithms is what a language lets us do, then it involves (only) syntax and semantics.}

How does this relate to the scenario? And how does one detect/verify "only"?

{Language consists of syntax and semantics, by definition.  If you're not talking about the former, you're talking about the latter, and vice versa.}

I still don't see how this relates to the Dr. Fobiz example. You lost me.

{Regardless what Dr. Fobiz creates a notation to do in a language, if it's a language, it's syntax or semantics.}

I meant testing if it represents the semantics the Doctor claims it does, not that it contains some random semantics regardless of source or purpose.

{You mean, what if the Doctor lies about the semantics of her language?  Then the statements that programmers write in the Doctor's language won't behave as the Doctor described.}

It's not a programming language. I repeat, "Dr. Fobiz could create a notation that he/she claims represent "semantics"."

{I don't know what that means.  Do you mean a meta-language designed to describe the semantics of a programming language, itself (necessarily) using syntax and having semantics?  That sounds like DenotationalSemantics.}

That's what influenced the Dr. Fobiz question/scenario to begin with. 

{Sorry, I'm not following you.  This "Dr. Fobiz" section has lost me.}

How do we know that DenotationalSemantics is really denoting semantics? It may just be converting between programming notations and the author merely claims the new version is "semantics". It looks almost like an Algol-style to Prolog converter, but I am probably not reading it right.

{If it makes reference to a given language and it's not denoting syntax, it must be making reference to semantics.}

What exactly do you mean by "making reference to"?

----

 Dynamic language -

 a = 3
 b = "4"
 c = "C"
 
 add(a, b) returns 7
 concat(a, b) returns 34
 add(a, c) fails

Type "tag" is not needed. 

Feed the wrong type to a process, it fails.

''Those particular operations don't necessarily need or use a type tag. However, that does not mean that the entire language has/uses no tags. Other operators may potentially expose the existence of a tag. In short, it's an '''insufficient test set'''. Overloaded operators are often a source of difference. What are you trying to illustrate anyhow? -t''

''I should point out that one may never know for sure if a language uses type tags, barring dissecting the interpreter EXE. ColdFusion acts like it has no tags (for scalars) so far, for example, but that does not mean that a case may someday be found that can only be (or best be) modeled/explained with tags.''
-------
'''Procrast-A-Tron'''

As a though experiment, it may be possible for the interpreter/model to not evaluate expressions until it absolutely has to. In other words, store the expression itself (or partially evaluated sections of it), and collect up (append or prepend, perhaps with parentheses) such expression until the last possible moment, perhaps at the output operation. There may be no need to finish each statement at the end of a given statement.  LazyEvaluation? -t

''Sure LazyEvaluation is fine; it's fundamental to certain FunctionalProgramming languages like HaskellLanguage.  It's trickier in imperative programming languages, because side effects may require the developer to consider the effects of LazyEvaluation.  Otherwise, it's invisible to the programmer.''  

''For example, many DBMS engines use a form LazyEvaluation to only retrieve rows or tuples as requested by the query result consumer, so that (for example) "SELECT * FROM V''''''astTableOfDoom" will not retrieve any more rows than are asked for by the process that sent the query.  If that process never looks at the rows in the resulting RecordSet, the DBMS won't retrieve even a single row.  If that process only displays ten rows (say, on a Web page), then only ten rows will ever be retrieved from the DBMS and its V''''''astTableOfDoom.  That's also true of a query like "SELECT * FROM V''''''astTable1, V''''''astTable2", which is an outer join that could produce a RecordSet of COUNT(V''''''astTable1) * COUNT(V''''''astTable2) rows, except that if the query process only ever displays five rows, the outer join will only ever process and produce five rows.''

''However, in general LazyEvaluation does not change what a statement like "a = foo() + b;" does; it's an optimisation rather than a change in semantics.''

Without an objective way to compare instances of semantics, I cannot verify that claim.

''You can objectively compare semantics using DenotationalSemantics, HoareLogic, or other formalisms.''

Can you use those to prove there is some kind of universal or canonical "semantics" in typical dynamic languages? Remember, you cannot just show one possible "implementation" (for lack of a better word), but must also demonstrate your claimed patterns are either the only possible semantic patterns, or are those commonly used by regular developers (who many don't know or care how interpreters are actually implemented, I shall remind you).

''In principle, yes.  I can use DenotationalSemantics to formally demonstrate the same semantics for a set of languages.  It would be a lot of work, though, and it would merely be a formal presentation of what can be shown trivially:  Allowing for (slight) syntactic variation, a statement like "a = foo() + 3 + c;" or constructs like "if (p) {} else {}" or "while (q) {}" have the same semantics in every popular imperative programming language.  Do you disagree?  If so, can you show how any of these examples varies in semantics from language to language?''

Regarding DenotationalSemantics, see PageAnchor Hoare_Horror. And the bottom question is trying to flip the burden on me, which isn't going to work. The default is not that semantics are the same. I have no way to rigorously compare "semantics" any more than I can compare "hate" in one man's mind to "hate" in another man's mind. Human ideas have have not been universally codified so far. If you claim they are the same then rigorously show they are the same. Otherwise, the default is "unknown". (External notations, such as programming code, are "lossy" representations of human ideas, or at least have not been proven to be complete representations of human ideas.)

''The bottom question isn't "trying to flip the burden" on you, but simply to emphasise the point immediately before it: Allowing for (slight) syntactic variation, a statement like "a = foo() + 3 + c;" or constructs like "if (p) {} else {}" or "while (q) {}" have the same semantics in every popular imperative programming language.  That is indubitable.  I have no idea how "human ideas" is relevant, unless you're still erroneously believing programming language semantics exist only "in the head".''  

Semantics outside the head '''cannot currently be scientifically analyzed''' in a rigorous way, REGARDLESS of whether it exists or not. (Same probably applies inside the head also). Thus, to say anything ''specific'' about these possible in-machine semantics is likely futile. IF you find a way to scientifically isolate and analyze and objectively compare in-machine semantics of interpreters, you may deserve a Nobel/Turing prize. Until then, stop pushing this fuzzy issue. We are perhaps wondering off topic anyhow; what does this have to do with "values"?

''Semantics can currently be scientifically analysed, in a rigorous way, using DenotationalSemantics.  However, in this case, it's so obvious as to be unnecessary -- there is no need for DenotationalSemantics to recognise the inescapable fact that "a = foo() + 3 + c;" or constructs like "if (p) {} else {}" or "while (q) {}" have the same semantics in every popular imperative programming language.  If you disagree, please identify a popular imperative programming language where the semantics of any of the three quoted examples differ in semantics.''

You said the same thing earlier re "obvious". I won't repeat my response to it. If you can demonstrate commonality using DenotationalSemantics, please do. Fuzzy words aren't cutting it. And remember that the existence of a DenotationalSemantics for such by itself does not establish commonality; it may be one "encoding" among many possible solutions for the same translation/problem.

[The existence of other possible solutions is a non-issue. If there exists a single semantic for all of them, that is sufficient to prove (you know, that item at the top of the EvidenceTotemPole) that there is a common semantic. All of the languages that I know of (c, c++, c#, php, etc.) use the same semantics for those constructs. Can you come up with any that don't?]

For the sake of argument, I'll agree for now that you showed that a common semantic CAN represent our target language set. However, that does not by itself prove that there are NO ALTERNATIVE semantic models that can do it ALSO. Thus, if your semantic model has your kind of "values", that alone does not mean that all possible semantic models have your kind of values. This is what I mean by the "uniqueness requirement". Put a slightly different way, showing that semantic model A is valid for set X does not rule out the existence of another semantic model B that is also valid for set X. What you need to show is that ALL POSSIBLE (valid) semantic models for language set X have feature V (V = your style of "value", or whatever else you claim is canonical or necessary). -t

[We haven't claimed that there are no alternative semantic models. There are, in fact, infinitely many. But, they will all be equivalent to the common semantic (just like 1+1 is equivalent to 0+2 by virtue of evaluating to the number 2). So your insistence that we prove uniqueness is just a RedHerring.]

Arrrg. Fine, then '''prove equivalence'''. I shouldn't have to ask. We have an objective (or agreed-upon) way to do it with real-number expressions, so make/find/invent the equivalent equivalence-finder for "semantic math". You accuse me of RedHerring, so I'm accusing you of delay tactics. You act like you opened Pandora's Semantic Box, but don't know how to use it right, inventing layers or excuses and what-if's to delay. (Technically, "Feature V" could be "equivalence of your Value thingy". I didn't rule that out above so technically I didn't exclude equivalence. If you want to get anal...) Let me offer an improved version:

   What you need to show is that ALL POSSIBLE (valid) semantic models for 
   language set X have feature V or its equivalent.

[Actually, we don't have a unique way to do real-number expressions. The two most common are Cauchy sequences and Dedekind cuts. There are infinitely many other ways to do it that we haven't bothered to name as well. They are all equivalent in that they assign the same truth values to sentences in the language of real numbers. This is, in fact, exactly what is happening with the semantic models for computer languages. As for your proof, in order for two semantics models to be models of the same language, they must give they same results. Hence, they must be equivalent. QED.]

What is "same truth values"? I've been out of college for a long time, so have to ask such things.  Re: "In order for two semantics models to be models of the same language, they must give they same results." -- I don't disagree, but how does that relate to our discussion? We need to demonstrate equivalent semantics, not equivalent languages. Or perhaps I don't know what "they" refers to. Anyhow, for arithmetic, most humans with some education have agreed on a standard notation and "processing rules" (for lack of a better term) for this notation. And we've agreed on what "equivalance" means in that notation such that we have an agreed-upon "algorithm(s)" that tells us that "a + a" is equivalent to "2a". More specifically, the notation's rules allow us to convert a+a into 2a and back unambiguously. To do the same thing for semantics, first you need to establish or find an agreed-upon notation and it's rules, and then us it to show that all target languages have equivalence, or at least equivalent parts (such as your version of "value").

[The "same truth values" means that the truth values are exactly the same. If one model says 1+1=2 is true, then the other model, to be equivalent, must also say 1+1=2 is true. Similarly with false statements. (Since there aren't any other truth values, we are done.) As for your notational rant, we haven't all agreed on a standard notation, we use a wide variety of notations. E.g. I + I = II. 1 + 1 = 2. One plus one equals two. etc. In addition, there is no need for an agreed-upon "algorithm" that tells us that "a + a" is equivalent to "2a". "2a" is defined, by fiat, to be "a+a". It is, to bring this back to the larger discussion, the semantics of "2a" that allow us to go back and forth between "2a" and "a + a". To show that different semantic models are equivalent, we only need to show that they give the same answer to question about semantics. I.e. What I showed in my previous response.]

There's seems to be ambiguity about whether we are comparing equivalency of semantic models, languages (syntax), and algorithms. Maybe we need to invent a pseudo-notation where we can state rules something like:
   if semanticsAreEquiv(A, B) And languageHasSemantics(lang01, A) And Foo(lang02) Then
      print("Languages Are Equiv:", lang01, lang02)
   end if



----------
PageAnchor manuals_472

Continued from ValueExistenceProof. It got so full it caused a server-side Perl memory error. (I've never seen that before on this wiki.) -t

''"Works" simply refers to what the language does with the machine, which is described in every programming language reference manual, and which is known precisely by the author of every language implementation, and by everyone who reads and comprehends its source code.''

So you claim. And you agreed that Php's online documentation was poor, at least in areas related to types. Thus, at least for SOME languages, one is left to their own devices and  experiments to model type-related behavior. The rest are vague also in my experience. Nobody has figured out how to do it well, so the authors all copy prior garbage's traditions, keeping the garbage and fuzz alive.

''Whilst PHP's manual is notoriously bad, most online documentation for popular imperative programming languages is quite good.  However, it almost invariably assumes prior knowledge of both programming and computer architecture.  Lacking one or both prerequisites, I expect some might find language references vague, and lacking the latter would make almost every technical description seem vague, obscure or opaque.''

* Computer architecture? Do you mean interpreter architecture?

* ''No, I mean computer architecture.  Notions of "value" and "type" are fundamental to computer architecture.  Machine registers store values.  Machine opcodes operate on values of specific types.  And so on.''

* Without a clear definition of both of those, I cannot evaluate your claim. The machine-level language certainly has operators that operate on different types (2 byte integer, 4 byte integer, double precision, etc.), but they don't manage or enforce them; it's up to the programmer or compiler etc. Machine language is not Php. There are similarities, yes, but still different kinds of things. Php could be implemented with Tinkertoys or Rube Goldberg toaster parts. One shouldn't assume a programmer has knowledge of machine language anyhow. It's handy knowledge to have, but not a necessity (except maybe if authors choose to base their documentation around such idioms, but that's an arbitrary choice influenced by tradition.)

* ''The definitions can be found in any standard text on computer architecture.  Type management or enforcement is not particularly relevant; note that Forth has no TypeChecking, and in C/C++ its straightforward to explicitly override it.  Obviously, machine language is not PHP, but the terminology used at the lowest machine level -- values and types -- applies equally to higher-level languages.''

* The definitions are vague. We've been over that already. And I'm not sure they are fully comparable. They have some conceptual overlap (as best I can conjure from my mind), but that doesn't mean "applies equally".

* ''They are not only comparable, they are the same.  Values and types are values and types, regardless of language level.  They may vary in how they're exposed, accessed, or defined, but they are conceptually the same.''

* You should have predicted by now that I'm going to ask "how does one measure 'conceptually the same'"?

* ''By studying the roles they play in both high-level and low-level languages.''

* That's a rather non-specific answer. One can observe and "get a feel" for something, but feelings/notions are difficult to communicate across heads.

* ''It is a rather non-specific answer, but an accurate one.  By studying values and types in programming languages, you soon appreciate that they're they're the same in everything from assembly language to popular 3GLs.''

* Non-specific but accurate? Even if true, it's not a useful answer for our purposes. We cannot scientifically analyze ideas/feelings/notions locked away in heads in any detail.

* ''There's nothing here about ideas/feelings/notions.  It's about language semantics, which are defined and documented by humans sufficiently to be implemented in interpreters and compilers.  Ideas/feelings/notions may be part of the motivation for designing a language, but they play no role in the specification of a language.  The specification of a language defines syntax and semantics.  Examining the syntax and semantics of assembly language and 3GLs reveals that their fundamental notions of value and variable are the same, modulo some representational issues.  For example, the type of a value is almost invariably assumed in assembly language, because there is no TypeChecking.  It's still (obviously) a value, and published texts refer to it as that.''

* My model does not conflict with most written descriptions not targeting language implementators.

* ''Yes, it does.  Most language references do not conflate values and variables.  The PHP manual is a notable exception, freely conflating values and variables in a confusing (and occasionally misleading) fashion.  Is that where you picked up the notion to conflate values and variables?''

* I don't "conflate" them. They are not the same thing IN my model. YOU conflate them because you try to interpret "value" in the way you want. (Since "value" is overloaded, neither is clearly "wrong" based on common word usage.)

* ''Values and variables are distinct in my descriptions, so how do I conflate them?  Values and variables use the same structure in your model, so how do you not conflate them?''

* They are distinct in my model also. You conflate them when describing my model's usage by using your own personal definition of "value" to re-label the parts. And don't give me the tired line of "that's the way the ComputerScience/Documentation Gods do it also", or I'll kick your cats in the nuts with pointy boots. My model does not contradict informal descriptions (for app programmers), and the implementation-centric documentation is for a specific implementation, not necessarily the "proper" or unique mental model. The informal doc doesn't talk about stacks for example, but the implementer doc does. Thus, existence of a usage of '''"value" in implementer docs can't be said to be canonical any more than stacks are.''' Usage of "value" is vague or overloaded in app coder docs, and implementation-specific in implementer docs. You can't seem to have your cake and eat it also.

* ''Dude!  What is it with you and my cats?  They don't even '''have''' nuts, given that one has been neutered and the other is female.  Your model conflates values and variables unnecessarily and pointlessly, and your claim of "simplicity" by avoiding nesting is specious at best.  There's no evidence that programmers, even weak ones, have difficulty with "nesting".  Your choice of XML as a notation, in fact, completely eradicates this as an argument, because XML is almost invariably nested, usually to multiple levels.''

* As already described, it does NOT conflate them. Your claim is false. You are using and repeating personal definition favoritism out of stubbornness. If I used your definition/description of "value" in my model, then it may indeed be "conflation", BUT I AM NOT USING YOURS. And the rest are issues I've been over at least twice, probably around 5 times. There will be no 6. In short, it's a WetWare AnecdoteImpasse at which point I suggest LetTheReaderDecide rather than re-re-re-re-re-re-invent the debate wheel.

* ''Doesn't your model use the same structure or "record" for variables and values?''

* No. 

* ''I thought it did.  What structure do you use for variables?  What structure do you use to represent what is returned by an expression evaluation, or a function invocation?''

* You are playing word-games here. You are using your pet definition of "value" to compare. I know you insist your version of "value" must be clearly identified in any such model to avoid some kind of what appears to be a poorly-indentified linguistic mental canonical notion collapse, but I hope we don't reinvent that debate here yet again multiple times repeatedly in a redundant fashion. Without rigorous WetWare studies, it's an AnecdoteImpasse.

* ''I'm not playing word games; I'm asking simple questions.  Again, what structure do you use for variables?  What structure do you use to represent what is returned by an expression evaluation, or a function invocation?  My use of "value" has nothing to do with any "poorly-identified linguistic mental canonical notion collapse" (whatever that is) and everything to do with reflecting canonical semantics, which themselves reflect well-understood popular imperative programming languages and the machine architectures upon which they run.''

* You are defining value as "the structure that expression(s) return", it appears. '''You made that definition up'''. I shall not accept made-up definitions as "canonical". Some personal or writer's notions may reflect that, but it's not universal, as "value" is a hazy, overloaded word. As a working assumption,  I do agree that expressions "return values", as they do in my model (and return other things), but your addition of "structure" is contrived. -t

* ''I didn't make it up.  It's derived from numerous computer architecture and programming language references and texts.}

* Incorrect. Not the way you stated it, no. That may be your personal interpretation of what you read, but that does not make that particular wording canonical.

* ''No, it is correct.  A value is always a representation associated with a type.  I can't think of a case where a value isn't that.  Without the type, we can't interpret the representation.  Without the representation, there is no data with which to perform operations on.''

* Like I said before, it *is* associated with a type in my model also. And being "associated with" is not necessarily a "structure". You are being waffly and playing fast and loose with language.

* ''"Associated with" is shown with a notation.  One way to notate it is to use a structure.  The problem with your model is that when you associate a type with a representation in your model, you use that same notation to represent variables, in which it is inappropriate to associate a type.}

* I agree that "one way to notate it is to use a structure" but it's not the only way and thus should be removed from your definition as an absolute requirement. As far as the tag model, if we are talking about YOUR version of "value" (which differs from mine), my model does not have such. There is nothing to conflate if there is no second thing to be conflated with. It's like doing the tango with yourself. (Well, you probably do, but that's TMI.)

* ''My "absolute requirement" is not the structure, but the clear indication that a value is a representation associated with a type.  The only place your model clearly associates a value (for your use of "value", I use the term 'representation') with a type is in your definition of a variable.  That is contradictory to conventional understanding of dynamically-typed languages.''

* As it is worded above with "structure", it's wrong then. In my XML, the type is "clearly associated with" the value. "Associated" does not require being on the same level or a lower level of nesting/containment. If you want to put in a level requirement, please do, but I'll hold you to prove such is a canonical rule instead of just claiming it's canonical or common. Claims are worthless without evidence. I already know you THINK it's canonical. You don't have to keep saying it; just prove it this time. Repetition may have worked on your mother, but it does not work on me.

* ''Yes, but in your XML, isn't the type "clearly associated with" the variable in exactly the same way it is "clearly associated with" the value, because the same structure is used for both variables and values?''

* "Exactly the same way"? Not sure what you mean there. And, yes, associations don't have to be unique. If you want to refine your "rule" to exclude other family members, be my guest, with the usual caveats. As written, I don't violate your "associate" rule (before the "structure" addition).

* ''I explain "exactly the same way" in the same sentence.  You use the same structure for variables and values, right?''

* No. Do you mean the equivalence of YOUR version of "value"? My model has no directly counterpart to that, thus there are not two things to compare.

* ''Let me ask a different way:  You use the same structure for mutable slots (aka variables) and the result of evaluating an expression, right?''

* Yes.

* ''Does that not imply that we should be able to assign to the result of evaluating an expression?''

* No, it implies nothing. We've been over this already. "Outside" code does not have access to internal variables.

* ''But it's the "inside" code (i.e., inside the interpreter) that has equal access to both variables and the results of evaluating expressions.  Doesn't that risk unintentionally mutating the result of evaluating an expression?''

* We've been over this already. It's a "toy" model for experimentation: we want the parts to be easy to fiddle with, and kept simple; thus simplicity trumps safety.


Then mine them for the best definitions of words such as "type" and "value", and bring them forth to this wiki to be analyzed. Generally my experience is that most people like concise crisp foo-bar/hello-world style examples and don't dwell on explanations, especially for something as ethereal and overloaded as types.

''That's what I've done at the top of TypeSystemCategoriesInImperativeLanguages.''

I see a model(s), not samples, at least not thorough samples. I've created some code snippet example pages on this wiki also about dynamic types. But, I'm striving for a prediction model also.

''The samples I've provided are illustrative of all possible cases.  More samples would be repetitive.  There's no need to provide a sample of both "1234" and "1235", to indicate that it works with both even and odd numbers, for instance.''

I thought you admitted that you only target the most popular dynamic languages, and thus ignore possibilities such as "soft" polymorphism in D1 languages? And then I pointed out that I do consider such possibilities because domain-specific and product-embedded dynamic languages are relatively likely to be encountered even though they don't make the top of the charts. (I'm not certain the popular D1 languages don't use soft polymorphism, but won't make an issue of it here.) If you want to agree that our models are for different purposes or language sets, that's fine. I have no problem with plurality of models.

''By "all possible cases", I meant in the context of popular imperative programming languages, and I don't limit it to DynamicallyTyped languages.  If I see evidence that any popular imperative programming language employs "soft polymorphism" as part of its operator dispatch mechanism, then I'll include it.  I've not yet seen such evidence.  I know of no programming language, popular or otherwise, that explicitly provides "soft polymorphism" as default behaviour of its built-in operator dispatch mechanism, though it can be added explicitly via the subtyping-by-constraint mechanisms of TutorialDee.''

That's fine, we'll agree that our models are optimized for different territories, or at least the territories have different borders.
----

{How do you distinguish fuzzy writing from fuzzy understanding?}

To be honest, I can't. But I've seen good technical writing and know what works (at least for my WetWare), and that is NOT it.

{I think if all the technical writing you've read still hasn't clarified values, types and variables -- pretty fundamental stuff -- maybe you should try some exercises to think about it differently.}

I did, and came up with the Tag Model and TypeHandlingGrid.

{I'd be curious to know how you think programming languages actually implement values, types and variables, as opposed to how you'd prefer to model them.}

Why does it matter? We have enough issues on our plate such that we shouldn't invent more without reasons. I'm not attempting to mirror actual interpreters, at least not as a primary goal. They are designed for machine efficiency, not necessarily human grokking efficiency. Different primary goals.

{I think it might significantly help me to understand and appreciate your model, and its justifications, if I understand your interpretation of values, variables and types.}

My interpretation of implementation? Or how I personally prefer to think of them? Those may be two different things. In my opinion, it is probably not good to get hung up on such. The tag model does not require a solid definition of any of those; the names used for the parts are merely UsefulLie''''''s for the purpose of the model and are not intended to fully match actual usage (and I doubt any model could match 100%). 

{If your "interpretation of implementation" and "how [you] personally prefer to think of them" differs, then it would be most helpful -- and appreciated -- if you would discuss both.}

My description of the tag model is pretty close to how I think of the processing now. Whether it was always that way, I don't know. I don't remember. But in general I mentally use or start with an open-ended structure(s) something like this:
  
  <object name="..." scope="..." type_tag="..." value="..." etc="...">
A given situation uses attributes it needs and doesn't use those it doesn't need. That way, I don't have to pre-classify everything. Trying to classify and label everything can drive one nuts and is often confusing, unnecessary, and inflexible. (They may nest as needed, such as for arrays.) If I was going to implement it with machine speed and efficiency in mind, THEN I'd try to classify the entities involved into distinct categories and make hard-wired structures. And the resulting structure/entity names and layouts may differ per language.

{That certainly addresses "how [you] personally prefer to think of them".  How about the "interpretation of implementation"?  Do you believe that is how interpreters and compilers work internally?}

I'm not sure I understand the question, because I didn't describe an actual implementation, but rather the process of going from a draft design or a non-resource-optimized design to one that is. In practice they usually probably push your style of "value" on stacks, but I am not an expert in that area.

{I originally said, "I think it might significantly help me to understand and appreciate your model, and its justifications, if I understand your interpretation of values, variables and types."  You replied, "My interpretation of implementation? Or how I personally prefer to think of them?"  I answered, "If your 'interpretation of implementation' and 'how [you] personally prefer to think of them' differs, then it would be most helpful -- and appreciated -- if you would discuss both."  You responded with your "<object name=...>" example.  I said, "That certainly addresses 'how [you] personally prefer to think of them'.  How about the 'interpretation of implementation'?  Do you believe that is how interpreters and compilers work internally?"  Does that clarify the question?  I'm asking you how you think interpreters and compilers implement values, variables, and types.}

I don't think about it much. I'm happy with a predictional model. 

{That's fine.  Think about it for a moment, and then let me know how you think interpreters and compilers implement values, variables, and types.}

Why should it matter? They are designed and tuned for machine efficiency and thus may not represent a model convenient for human dissection. In fact there is '''no reason for an actual interpreter to follow human notions''' whatsoever if mirroring such notions results in a performance cost compared with the alternative. (Assuming error messages are still useful to humans.) I've written lab-toy stack-based expression interpreters in college (integers only to keep is simple), and they didn't match the tag model, but again I don't see how that matters. Stacks are not "natural" to humans for expression evaluation and so I don't see anybody arguing to keep them in a type-analysis model, unless one's goal is learn how to make production interpreters.

{Why should it matter?  As I wrote above, it might significantly help me to understand and appreciate your model, and its justifications, if I understand how you think interpreters and compilers implement values, variables and types.}

Like said, I don't think that much about how they actually do it. I will agree they probably model "values" similar to how you do it, because it's machine-resource-friendly to do it that way, as already explained.

{How about variables?  How do you think they're implemented?}

I don't give them much thought either. Maybe I did in college many moons ago, but I don't remember my thought patterns back that far.

{Why are you evading giving an answer?}

I have no known way to turn my speculations into words at this point, and won't make a stronger effort without a sufficient justification.

{I suspect your evident lack of concrete understanding is precisely why you feel variables and values should be conflated.}

Yes, I possibly do lack a concrete understanding of how interpreters are ACTUALLY built. But we are not discussing production interpreter construction. It's only possibly an issue if my model produces wrong output.

{As I wrote above, it might significantly help me to understand and appreciate your model, and its justifications, if I understand how you think interpreters and compilers implement values, variables and types.  Whether your model produces wrong output or not is something I shall determine when TopsTagModelTwo is complete.  Until then, I would only be speculating about the as-yet unwritten parts of your model.}

What unwritten part are you most curious about?

{I'm not curious about any unwritten parts of your model.  How can I be curious about something that isn't there?  What I meant is that in order to determine whether your model produces wrong output or not, I have to make assumptions about the parts that haven't been written yet.}

Whatever. If you have a question about "missing parts", then ask.

-----------------
'''Assumption of Notion Existence'''


For the sake of argument, even if there were a very common and solid notion of your flavor of "value", what's wrong with breaking that notion to simplify a particular model? We can add disclaimers to make sure the deviance is known. Is it too "sacred" or important to dispense with? Road maps quite often dispense with actual stuff to simplify their model of roads. Light-colored cement roads are still printed in the same dark ink as dark roads, for example. And the road width is often not to scale. Plus, it's a compromised projection of a round surface into flat paper. (Rounded paper is not impossible, just impractical.) The map reader knows the maps lies about many things, but accepts those lies to keep the map easier to read for the purpose of navigating roads. '''The road-map lies to tune it to a specific purpose.''' Why can't a "type" model do that same?

{Your model's conflation of values and variables is complex (your model demonstrates StampCoupling), confusing, contrary to common understanding, and implies that your value/variable conflation can be assigned to in contexts where assignment is pointless.}

You keep claiming it's more confusing etc. than your model, and I call bullshit. Repetition of bullshit doesn't make it non-bullshit. You just got used to a particular (machine-centric) model and mistake it for "common understanding". As far as StampCoupling, it's only a suggestion, not a "hard" rule, and needs to be weighed against other design "suggestions" and techniques. (See also WaterbedTheory and CodeChangeImpactAnalysis).

{Even if we accept StampCoupling, it's still confusing to treat values and variables as the same, and it implies that your value/variable conflation can be assigned to in contexts where assignment is pointless.}

But I don't have your kind of "values", so there is nothing to treat as the same. Thus, there is no stamp to couple. An analogy would be Dell using its own computers for its own employees. It "externally" sells PC's to the public, but it can use those same PC models internally for its own employees and operations. (Sometimes this is called EatYourOwnDogFood.) The public can't touch Dell's internal PC's because they are in locked or secure buildings. This kind of variable usage has the advantage over your "value" of having a model-user-viewable reference name, which makes examining sub-parts easier. And it avoids the need for a nested structure; which appears to be poor normalization (at least in this model, which has no stacks etc.). As far as "it implies", that happens in your head, not reality, and probably not in others. I have no idea what whacky notion made you dream up the "foo()=x" scenario. And even in the rare case the model user smoked the same mushrooms as you to get the same idea and jury-rigged it in, it doesn't do anything; it's a glorified no-op. (Well, I suppose with enough mushrooms one could define and implement reverse assignments to mean "reformat the hard-drive and display an animated GIF of green monkeys flying out of Batman's ass". Oh wait, it's a ''reverse'' assignment, so the monkeys should fly ''into'' his ass. Semantics.)

{You may not have my kind of "values", but you use the same structure to represent variables and what is returned by functions and what expressions evaluate to.  Since variables can be assigned to, and since you're using the same structure to model variables as you use to model both what is returned by functions and what expressions evaluate to, then it follows that you can assign to that which is returned by functions and you can assign to that which expressions evaluate to.  If you can assign to that which is returned by functions, and assign to that which expressions evaluate to, then it follows logically that the assignment "foo() = 3;" and the assignment "1 + 2 = 5;" are both valid.}

You are lying or delusional. My model is not forced to do that. Stop being stupid already; I'm tired of debating such a preposterous and distracting claim. There is no gun to its head to force it accept and/or process such syntax, nor God of Logic forcing it to via lightning bolts. Your head is playing tricks on you. '''Reboot your head and try it again.'''

{No one said your model is "forced" to do anything.  What your model does is permit assignment in places where assignment wouldn't normally be permitted.  It permits building languages where the assignment "foo() = 3;" and the assignment "1 + 2 = 5;" are both valid.  It's true that there is "no gun to its head to force it [to] accept and/or process such syntax", but there's nothing to prevent it, either.}

* It permits or does not permit whatever you want it to. You don't have to put a screen door on your house, but don't complain about mosquito bites if you don't. I can probably jury-rig an implementation of your model to allow such also.

* {No, it permits exactly what it permits.  It's true that you can employ whatever parts of the model you want to, and choose to use or not use its parts however you like, but if a model permits meaningless or pointless things and it can be trivially changed -- without loss of capability -- to '''not''' do meaningless or pointless things, then it's a better model if it doesn't permit meaningless or pointless things, and a worse model if it does.}

* It does NOT "permit meaningless or pointless things" unless you let it. Trivially changed? How exactly? Note that every model/implementation is probably "fragile" in different ways, meaning small changes can result in big problems, but in different areas. It's sort of like human genes in that in certain genes, small mutations make for big birth defects. I doubt any design is free from such; it's a matter of trading one fragile spot for another. Perhaps a current design can be shored up via redundancy, but then it's also harder to change when you want to change it, and is more bloated.

* {It's trivially changed by separating values and variables, instead of using a single structure and API to represent both.  That is, after all, how actual interpreters and compilers are implemented (I know, I know), but it's done for a good reason:  Values and variables '''are''' distinct.}

*  Please demonstrate. I'm skeptical, and am skeptical yours lacks the same alleged "flaw" if the parser breaks down. Your structure has the same attribute "slots" to be used and abused.

* {If, say, an expression evaluation returns a value, and a value does not support assignment, then you can't assign to it.  If an expression evaluation returns your valvarueiable, it supports assignment, because valvarueiables are also used to model variables, and you have to be able to assign to variables.}

* Re: "and a value does not support assignment" -- What prevents that? If you have a GateKeeper type of interface/wrapper around your "value" structure, I suppose such is possibly outright preventable (if tied to other operations carefully), but that's specific to implementation or model. Sometimes KISS conflicts with safety scaffolding, but I don't see such scaffolding in your model. And having to "be able" to assign to variables does not mean one must assign to variables. Just because I have a gun that is expected to be '''capable of''' blowing off a person's face does not mean I'm obligated to actually blow off somebody's face.

* {Values are immutable, by definition.  So, they do not support assignment, by definition.  Variables are mutable, by definition.  So, they support assignment, by definition.}

* Say what? Implementations don't read definitions. Unless you explicitly implement it to be immutable, it will be mutable. Further, how would that stop such syntax from getting through the system? My model doesn't re-write to those kind of internal variables such that if they were made immutable it would not change anything. 

* {I expect a programmer, implementing the model in a programming language interpreter, would indeed make values immutable and variables mutable.  Using an OO language, for example, variables in a Category D1 language would be implemented as something like:}
   class Variable {
       private String name;
       private Value value;
       Variable(String name, Value defaultValue) {
          this.name = name; 
          setValue(defaultValue);
       } 
       void setValue(Value value) {this.value = value;} 
       Value getValue() {return value;}
   }
* {Values would be implemented as something like:}
   class Value {
       private bitstring representation;
       private Type type;
       Value(bitstring representation, Type type) {
          this.representation = representation; 
          this.type = type;
       } 
       bitstring getRepresentation() {return representation;}
       Type getType() {return type;}
    }

* Okay, the constructor-only approach is reasonable for a ''production'' system, but this is not a production system. We want to leave them mutable so experiments can be done, and we want them (internally) addressable similar to a variable so experiments can reference them. Efficiency and safety are ''not'' the primary goals. Further, we '''can make them immutable without nesting them'''. For example, we could add another attribute called "mutable", or perhaps "object-type" and have the object type enumerations of "external-variable", "internal-variable", and maybe "constant". (I'd call the XML entity "object" in a fancier model, not "variable", per below.) But in my opinion that's GoldPlating for the purpose of the model. '''Safety equipment is purposely removed to keep the guts simple and visible and tweak-able.''' Based on experience with your personality(s) on this wiki, I expect you to balk loudly at this decision. I make such decisions based on my experience and estimations of end-user WetWare, and you do the same, yet we come to different conclusions about end-user WetWare (or perhaps have different goals in mind for the model). It's an AnecdoteImpasse. -t

    // Example: fancy-object-39
    <object name="..." scope="..." mut_type="<var>|<internal-var>|<const>" type="..." value="...">
* {That might be reasonable if you're creating a toy interpreter for experimentation.  Is it a reasonable model?}

* Yes, the Tag Model and it's ilk are indeed a "lab toy" for experimentation and study. I thought I've made that clear already. I've already agreed that your version of "value" is probably more efficient for machine-centric production interpreters. For one, stacks don't need explicit "value ID's" because they use stack positioning to "line up" the parts properly (assuming no nesting-oriented syntax errors). But stacks are too unintuitive to many for the purpose of studying type-related behavior explicitly. Thus, it uses an approach more similar to how one does it on paper, but with explicit "labels" for each step, making the "values" (for lack of a better word) closely resemble variables; and since they are so similar, I roll them together with "external" variables so that users don't have to learn about and remember the rules and API's of two different "kinds" of objects. Incidentally, I have seen another language use a very similar "internal variable" approach for expression reduction, at least in debug mode. Unfortunately I don't remember the language name, though. It may have even been a compiler, not an interpreter. But it stuck with me as a clever and KISS-y metaphor, or UsefulLie. (Related: ListAndSingleOperatorExplicitnessPattern)

* {The Tag Model has ilk?  From your description, it isn't a model.  It's an experimental language run-time.}

* I was referring to the "in a fancier model" (or version) above. What do you mean by "language run-time"? It does not limit itself to a specific syntax, for example. It could be used to emulate Php, JavaScript, VB-Script, CF, etc. As given, it lets the user do the syntax-to-API conversion by following the examples. But that step could be automated, and tuned to a specific language. It's a "portion of a lab-toy interpreter", if you will.

* {A language run-time is the core "engine" in interpreters and some compilers responsible for executing the result of successfully parsing the user's source code.  It typically provides facilities for handling flow control, operator dispatch, variable retrieval, type checking, exception handling, threading, interfaces to OperatingSystem services, and so forth.}

* I'm not going to get caught up in the word "model". Consider it short-hand. It is what it is. It's a "kit for building prediction models of type-related behavior for said language group". It could also be viewed as a lab-toy interpreter, or parts of an interpreter.

* {That's fine, but it's not a model.  It's not modelling anything.}

* It's a "model-building kit", roughly analygous to an RC airplane model building kit. It gives you common and typical parts and templates and examples, but you can customize it per specific target plane model, such as a "Fokker F. VII". (I call it a "model" as short-hand).

* {Where are the instructions for how to use your "model-building kit"?}

* TopsTagModelTwo

* {I see nothing that explains how to build a model.}

* Well, I don't know what's missing that your brain expects. Perhaps a link to some other kind of comparable model document could be provided as sample of such documentation "done well". Never mind; I've seen what you consider "good" already. Scratch that.

* {Something that would explain how to use TopsTagModelTwo as a "model-building kit" would be helpful.}

* Well, I don't know what's missing that your brain expects. Perhaps a link to some other kind of comparable model document could be provided as sample of such documentation "done well". Never mind; I've seen what you consider "good" already. Scratch that.

* {An explanation of how to apply it, or what to apply it to.  I would expect a "model-building kit" to describe its parts, their purposes, how they relate to each other, and how they're used to create a model -- which itself should consist of a description parts, their purposes, how they relate to each other and rules for relating them to each other, and how they relate to the system they're modelling.}

* I did that already. Why it doesn't click with you, I don't know. I cannot solve that puzzle at this time.

* {On TopsTagModelTwo, you wrote (for example), "The modelling kit can create descriptive imperative instructions and/or pseudo-code models..."  How?}

* I removed the word "instructions". I don't remember why I put it in there; perhaps it was a typo.

* {Without "instructions", it's, "The modelling kit can create descriptive imperative and/or pseudo-code models..."  How?}

* It's described below that. I agree some parts should be fleshed out some more, but for the most part it should be clear to experienced developers. I'll gradually add to and improve it over time. If you have a SPECIFIC question, ask away.

* {I don't have anything more specific.  I suspect it's the parts that you say should be fleshed out some more that need to be fleshed out some more.  Perhaps there are aspects to your model that seem obvious to you, but aren't obvious to me because you haven't written them down.}

* Neither of us like the other side's writing style, finding it "non-clear". That's not news. I'm not sure what to do about it. Sometimes communicating with you is like communicating with an alien race with an entirely different background or mental model of software.

* {I think you'd find my writing style a great deal less "alien" if you had slightly more background in ComputerScience. I suspect I'm often writing assuming knowledge of computer fundamentals and computer architecture that you appear not to have.}

* Your definition/view of "fundamental" is suspect, possibly polluted by hardware concerns/exposure. '''Software is not really about hardware''' ("computer architecture"). The fact that you brought computer architecture into this strongly suggests you are misguided. In fact, I'd say programaming languages are more about communication with and between humans than machines. Their comparative lack of ambiguity is what allows them to be processed by machines, but also improves inter-human communication. If our languages are primarily shaped by machine concerns, then we are doing it wrong, because machines can be improved if they turn out to be the bottleneck. '''Ambiguity is the biggest shaper of programming languages, not machines.''' Please continue any such replies about this at ProgrammingNotAboutMachines. And you seem to lack fundamental knowledge of the scientific process, not understanding the role of models in it. Prove you are smart and objective, don't just claim it. Claims are cheap on the web: mere commodity hot air and bragging. ItemizedClearLogic not based on word-play would be a good start. Even with word-play it would be a step up from your fuzzy English "proofs".

* {Popular imperative programming languages are an abstraction of the underlying machine.  C/C++ makes this particularly obvious, but it's no less true of (say) Python and PHP.  Software is not about hardware, but it runs on hardware, and popular imperative programming languages reflect this fact.}

* The are NOT an "abstraction of the underlying machine". That's utter hogwash. And perhaps they were partly influenced by hardware concerns, but that doesn't mean one is forced to view them in terms of hardware. That they can be viewed in hardware terms is not the same as "must" be viewed in hardware terms, or even "best" viewed in hardware terms. If you can logically prove they are "best" viewed in terms of hardware, please do. But paint me skeptical. (To be moved to ProgrammingNotAboutMachines).

* {You don't think C, for example, is an abstraction of the underlying machine?  That's exactly why it was created -- to abstract away machine specifics, whilst still acting effectively as a generic assembly language for operating systems development.}

* C, perhaps, but that's a language-specific trait. Other Algol-influenced languages, especially dynamic ones, differ. The only machine-centric remnant I can identify in ColdFusion is the a maximum precision (number of decimal places) in floating point numbers. One does not have to worry about 4 byte numbers versus 8 byte numbers, etc. But even from a practical "external" matter, machines aside, floating point precision should probably have some upper limit. Otherwise writing un-formatted test output would take up gajillion screen-fulls. Thus, I'm not even sure I'd consider floating point precision limits to be a machine-centric issue. Maybe the existing limit is too small, but that's a minor thing to quibble about. For roughly 99.9% percent of programming thinking, I don't have to think about such machine issues (performance aside). (Note that I have not encountered issues with integer size in CF. There may be limits or conversion-to-floating issues with that, but I've never encountered them myself.)

* {VonNeumannArchitecture was influenced by algebraic notation, which in turn influenced language design.  Languages that implement mutable variables and imperative statements are all abstractions of the machine.  Languages like Prolog and Haskell, which implement significantly different semantics, are much less of a machine abstraction.}

* That statement difficult to verify. It more appears as if the '''marketplace determined which coding style became popular''', not hardware builders, and we cannot rip open millions of consumers from that era to study their neuron patterns (if they are still alive). You are welcome to present indirect evidence of such an association, but it's probably only spotty evidence and not reliable enough to make such generalizations. BASIC was pushed by the early microcomputer hardware builders because it was cheap, relatively familiar, fit in RAM, and didn't require a RAM-hogging code editor. However, despite temporarily popularity, programmers eventually drifted back to Algol style. Thus, hardware concerns were not sufficient to control the language choice in the longer run in that case. 

* Please reply at AreCurrentLanguagesShapedByHardware. This topic is growing TooBigToEdit. (The above may be shuffled there eventually.)

* {Sorry, no.  I'm not sufficiently interested in the origins of coding style to bother, and it's far off-topic from the main discussions here.}

* So are you conceding that our target programming languages have very little to do with "computer architecture" and that your "alien" statement was a mistake? If you simply don't want to bother to defend that particular statement at this time, that's fine, just be clear about that decision. It's rather accusational in tone such that I feel entitled to some form of closure here.

* {I concede nothing, and your feelings of entitlement to closure (or anything else) are irrelevant.  I'm simply not interested in following this unnecessarily discursive discussion down any more time-consuming blind alleys.}

* You spew about "computer architecture" and then run away from it? Coward!

* {More insults?  See http://www.stanford.edu/class/cs242/readings/backups.pdf for a classic on the relationship between Von Neumann style machines and imperative programming languages.  It's as true today as it was then.}

** [I think you want http://www.stanford.edu/class/cs242/readings/backus.pdf ]

** {Yes, thanks.  I typed it from another screen (long story) and typo'd.}

* Your statement that started this section is an insult. If you don't like insults, don't give them.

* {What did you find insulting?  I can't find an insult.}

** You seem to not understand common social mores. I'm not in the mood to explain it right now.

** {I've skimmed the text from the "Assumption of Notion Existence" heading to here, and I can't find any insult I've made. I've found insults you've made, like "You are lying or delusional" and "stop being stupid already".}

** I'll explain it on another day. I'm not in the mood for a social lesson today.

** {Explain it another day.  Today, could you just point out where -- in the text from the "Assumption of Notion Existence" heading to here -- I've insulted you?}


* I get a "not found" error on that PDF. And I don't dispute that languages share many things in common with VN, but sharing traits is not necessarily proof of causality. Like I said, many language styles have and had been floating around in the market place and orgs could use any they wanted. I see no evidence that fitting hardware was the primary driver of choice.


Another thing, if I replaced my XML structure with yours, the kit API's would do pretty much the same thing they did before such that if they have a flaw that allows bad assignments (for the sake of argument), it's not due the data structure. 

{Then the flaw in the data structure extends to the API.}

* There is no flaw. (By the way on the deleted "spat": I'll try to be respectful in this topic if you are likewise respectful to me. No calling people childish, stupid, liars, etc. Agreed? I admit, starting the last "rudeness war" was my fault and I apologize. -t)

* {I don't recall ever calling stupid or a liar, nor have I used any other insult.  I have, as I recall, called you childish.}

* They are only examples. "Childish" is an insult, by the way. Anyhow, let's all try to avoid rudeness and rudeness escalation. I know these discussions can be frustrating because we are dealing with issues of WetWare and meta-physics-like realities, which are difficult to describe and explain.

* {If I use "childish", it's only meant to be descriptive.  Distinguish that from, say, "shit-head" -- obviously an insult unless, in fact, you have shit on, in, and/or around your head.  (Note that I am not calling you a "shit-head".  In case there's any misunderstanding, I should also point out that I'm not calling you a dick, asshole, fuckwit, idiot, wanker, imbecile, moron, divot, plonker, twit, knuckledragger, cockmuppet, and/or derp, either.)  I don't find these discussions frustrating, but then I don't think they have anything to do with "WetWare and meta-physics-like realities".  As far as I'm concerned, they deal strictly with language syntax and semantics, and sometimes veer (perhaps off-topically) into language implementation.}

* That's the biggest load of horseshit justification for insults I've ever seen. I have plenty of "descriptive" ways to describe you, but I try to keep it to myself; and if I slip, I readily admit it's an insult. If I call you "stubborn" or "obsessive", for example, that's descriptive AND an insult. It's not mutually exclusive.

* {I don't know about "obsessive" -- maybe I am -- but I am definitely stubborn.  How is that an insult?  Sometimes you write in a childish manner.  How is that an insult?}

* I assure you, in the real world, a good portion, perhaps more than 50% of the adult population, would consider both of those words an insult (barring some special context). This should be obvious/common knowledge.

* {I'm not concerned about other people, obviously.  Why do you wish to insult me?  Does it make you feel better about yourself?}

* You insulted me with your "childish" accusation.

* {Then don't be childish, and I won't accuse you of it.}

* We'll make a deal: you don't be a stubborn repetitious pedant, and I won't be childish.

* {That seems reasonable, but how do you define "stubborn" and "pedant" (I can guess about "repetitious")?  Childish, in your case, is using insults and expletives.}

* I can assure you, adults use plenty of insults and expletives, especially on the web. That's not a distinguishing factor between age groups.

* {Indeed, and all such behaviour is childish, regardless of chronological age.}

* That makes as much sense as your "semantics" definition.


As a semi side note, I believe that some OO languages do allow something similar, as a shortcut for accessors whose logic can be redefined. But I don't remember the language. Thus, "myObject.setFoo(x)" and "myObject.foo=x" would be equivalent, and how the setting is done is up to the class coder such that it can trigger a function (setFoo method) to run. But I'm not necessarily endorsing such.

{The language is C#.  The semantics are those of typical accessors (i.e., get and set methods), but with syntax to make them look like references to member variables.  E.g., given "class C {int V {get; set;}} C c = new C();", you can write "c.V = 3; Console.W''''''riteLine(c.V);" which is effectively shorthand for "c.SetV(3); Console.W''''''riteLine(c.GetV());"  It isn't the same as assigning to expressions or function invocations -- e.g., "3 + 4 = 2;" or "foo() = 3;" -- which your model and its underlying API would apparently permit, because variables, expression evaluation results, and function invocation results are all represented by the same mutable structure, using the same API to access it, that permits assignment.}  

I'm not sure that's the language. The language I remember allowed one to redefine the "set" method to be anything they wanted, and would be roughly equivalent to "foo()=3". 

{Perhaps you're thinking of C++.  It allows you to redefine the '=' operator to be something you want, including things that aren't assignment, but then that's a change to semantics.  There's no way to redefine '=' to assign something to a function invocation or to an expression.}

{By the way, given that C++ is a language where you can redefine most operators to change their semantics, an expression like "a = foo() + b" can be made to mean something like "rotate object 'a' about the 'foo' axis by 'b' degrees". Many argue that doing so is questionable, because it no longer reflects canonical semantics.}

Anyhow my model only "permits" it if you break it or don't finish all parts of an interpreter built with it. Your model can also be jury-rigged. I'm tired of arguing over this; it's a silly obsession of yours. '''Do Not Feed The Obsessive'''. ENOUGH!

Please, find something more interesting to obsess on.

{It's not my obsession, but your model's serious flaw.  It can be fixed easily by distinguishing variables from values.}

Sorry, you are full of it. And using your nested structure probably wouldn't fix the "problem" because it seems to lean toward the API instead, but I'm not certain because I don't even know where this alleged problem is; I'm just guessing based on your vague description. '''The parser would typically reject such because expressions are not allowed/expected on the left side of an assignment statement.''' There's no reason to allow parenthesis or plus signs on the left of assignments. In fact, '''one would have to explicitly tell the parser how to handle such'''; it wouldn't accidentally show up. That's '''two hurdles''', at least, it has to pass thru: 1. Syntax checking, 2. Translation into API calls. And even IF those two hurdles break down, it would be like a no-op instruction anyhow; not affecting the output. Do you know what a no-op instruction is? I don't even know why I'm entertaining your silly notion. I should ignore it instead of feed stupidity, making it grow. That's why you can't talk to regular programmers, you get mentally caught up in dumb little things that regular people don't care about. "Ooooh, but this bicycle helmet doesn't prevent you from sticking a pickle in your ear! Oohhhhh ohhhh ohhh!"

Is your claim this?: My model (allegedly) puts more burden on the syntax/parsing side of things, whereas yours can catch such in a later stage if the syntax/parsing side breaks down or is omitted?

{Essentially, yes.  My model cannot implement a situation in which values or variables are assigned to values, or where variables are assigned to variables, or where expression evaluation results in a variable, because values and variables are distinct.}

The issue is accepting such statements, not the name of the intermediate parts. I see nothing in your model that would prevent the "foo()" being converted to an intermediate value. (It may be ignored, but the equiv is ignored in my model also, if parsing lets it thru, that is). Anyhow, it's a '''non-issue''' because the parser and API converter would normally not even recognize such a configuration; one would likely have to go out of their way to implement it (depending on algorithm used). Enough about this '''red herring'''.

{Even if the result of foo() is an intermediate value, you can't assign to it.}

In a section above, I've asked what specifically what prevents such.

{The definitions of variable and value.  The former is mutable and therefore permits assignment.  The latter is immutable and therefore does not.}

Search for "say what?"

------------------

Do you agree that for debugging and/or experimentation, having '''mutable and addressable (ID'd) "values"''' can be useful?

{No.  A value is such a trivial structure that requiring it to be "mutable and addressable" is unnecessary.  If a value needs to be "addressable", it is normally contained in a named or indexable structure.  That's the basis for constants in programming languages.  I can't imagine why a value would need to be mutated.  How often do you need to turn a 3 into a 4?}

During debugging to test alternatives. "Contained in a named structure"? I thought you were against that because it violated some secret Mason's semantics code or something. Anyhow, in ANY interpreter source code, the implementation of "value" will be potentially mutable. One can put an object wrapper around such to "lock it" from changing once it's created, but one can alter that code and remove the lock if they wanted. I chose to keep the implementation simple, but if you want to put locks on YOUR version, that's perfectly fine. I'm not dictating the absence of such features. A model/kit user can do all the SafetyGoldPlating they want. '''I don't forbid it'''. It's quibbling to complain about such.

{What kind of "test alternatives" involving mutating a 3 into a 4 might you need to do that can't be done by using the 4 value instead of the 3 value?}

There have been many times where I wish I could test alternative values/inputs without altering the source code or data to fudge it during debugging. I cannot name a specific UseCase that's easy to describe at the moment. But that's moot anyhow because one can put locks on any part of my model/kit they want. I don't forbid it. '''Lock away!''' if you feel that kind of thing is important. I doubt the vast majority of programmers would give a fudge, but if it's your thing, do it. You can even modify it to have "representation" instead of "value". Rename the parts and shape it to make your mind comfy and happy. You can even glue tits onto it if you are feeling horny. 

{Your model makes it impossible to "lock away" values without simultaneously having to "lock away" variables, because you use the same structure for both.  Re "glue tits onto it", etc., you're being childish again.  Stop it.}

No it doesn't. Add another attribute to the Variable XML structure that the accessor API's use to prevent changes. We've been over such already. One could also create two different "kinds" of variables (objects/things), but that complicates the model too much in my opinion. I'll value simplicity over "safety" since it is not meant for production interpreters. Plus, I want to leave in the ability to fiddle with internal values for experimentation. 

But you are welcome to adjust your copy any way you want. It's a free country. Instead of complain about it, build your own. Unless you come up with solid evidence it violates "common semantics" or something similar in a big and clear way, there's no justification to keep complaining about my version. You've failed to clearly measure "common semantics". Your version/interpretation of "common semantics" comes from your '''personal interpretation''' of your favorite written sources, NOT a clear and obvious and measurable pattern. You're being insistent based on weak (if any) evidence, which I interpret as stubbornness.

{As long as you make no claim that your experimental interpreter is a model of anything, I shall not object.  That includes not injecting commentary into discussions based on an assumption that your experimental interpreter is a model, such as using "type tag" in place of "type reference" or claiming that a value is an "anonymous variable", and the like.}

Please elaborate. This seems to assume some canonical model as a reference point. I already explained in bold that it may not reflect actual implementation of most interpreters. Why is this not good enough? Or are you back to making actual machine-oriented implementation the reference point? (You seem to waffle on that.) Otherwise, '''my arbitrariness is no more arbitrary than your arbitrariness'''. There is NO ONE RIGHT MODEL. And, I don't formally define "value" anywhere. And "type reference" is not an official certified term; thus, I'm not violating anything real. This again seems to be a case of MentalModelOverExtrapolation into a (perceived) objective truth of model, vocabulary, and usage of. Further, "type reference" implies a pointer to some central look-up table or the like, but there's no such table in the model (as originally given. You can add your own if you really want one.) Thus, it '''might introduce confusion''' without sufficient, if any, benefits to make up for that confusion.

{As long as you do not use the term "type tag", "hidden variable" or "anonymous constant" outside of discussions about your model; argue that values or programming language semantics do not exist; or treat terminology or aspects of your model that are unique to your model as if they should be familiar terminology and commonly-recognised aspects, then I shall not object.  I recall a couple of instances where you've used "type tag" or just "tag" -- in discussions unrelated to your model -- as if they should be familiar and understood.  If I see you do that or its ilk, I will object.}

So you can use working terms like "D2", but I can't? Sounds like a double standard to me.

{I have no intention of using "Category D2" outside of either discussion of your model, or discussion of TypeSystemCategoriesInImperativeLanguages.  I wouldn't expect it to be recognised outside of those contexts, so I wouldn't mention it outside of those contexts.} 

That's fine. If either one of us slips and uses something outside of context, we can kindly remind each other.

-------
(Diagram moved to IoProfile)
----
CategoryMetaDiscussion
----
NovemberThirteen