Continued from TypeSystemCategoriesInImperativeLanguagesTwo. 

"Associated with" by itself doesn't tell us how many types can be "associated with" a variable/value, when the association occurs, when it goes away, and how we empirically test for its existence. In a tag-free language like CF, one could say the string "123" is "associated with numbers" because it can be "interpreted as" numeric, or can be said to have a value that belongs in the "set of numbers". And this could become actual implementation in that a lookup table of all possible numbers (within size/precision limits expected), as "numeric strings" (for lack of a better term), could be created. 

''By the usual rules of English language, "a variable is associated with a type" means a variable has one type, because of the phrase "'''a''' type" in which both "a" and "type" are singular.  If a variable could be associated with multiple types, it would be written as "a variable is associated with multiple types" or "a variable is associated with types".  Whilst it is not unreasonable to say that the string "123" is "associated with numbers", it's merely an awkward way of saying that "123" is a numeric string.''

* But writers are often sloppy with "a". It's best to be explicit and say "one" if you mean one. "a" by itself does not rule out others. 
* ''I think "a type" is obviously singular.''
** It's possible for a typical dynamic language to have a "a='0';" statement in which "a" can "be" a string, number, and Boolean at the same time: 3 types. So it's NOT "obviously singular".
** ''Every value has a single type associated with its representation, necessary for the interpreter or compiler to recognise the representation.  See TypeSystemCategoriesInImperativeLanguages.  This is independent of whatever values of different types may be encoded in the value.  For example, a value "0" is of type string, but it may encode a number and a boolean depending on how individual operators interpret the string.''
** You are talking about a specific model. I'm talking about colloquial "type" related language and notions. When one is learning a model or reading a language manual, they often come in with the colloquial view, not a specific model's view. Remember, we are talking about how one may interpret "a variable is associated with a type". If you are assuming they read other material or rules first, please state that assumption(s) and justify it as a likely scenario.
** ''To the extent that how every popular imperative programming language handles values, variables and types is a "specific model", yes it is.  What I wrote is precisely the view that anyone learning programming should leave with, regardless what views they come in with.  Indeed, it doesn't matter what views they come in with.''
** Your "should" is dripping with idealism. If this gets back to our frequent re-debate about "typical knowledge of developers", then we might as well AgreeToDisagree and stick an impasse-flag into the soil here.
** ''If it's not expected that someone '''should''' gain an understanding from reading an explanation, what is the purpose of the explanation?''
** Like I said before, existing writing on "types" has been crappy, likely because nobody has found a way to do it better and so they each just re-copy the crappy documentation conventions from the last guy's sucky docs. If you are paid to build a bridge in the pre-Roman era, and the technology of the day is such that 50% of them fall down within 20 years, you don't have much of a choice other than copy the existing plans and conventions because you know of nothing better. (It's similar to NobodyEverGotFiredForBuyingMicrosoft.) It's kind of like our traffic problems in big cities: yes we know cars suck and that the sky above is mostly wasted, but nobody has found a way to make practical flying cars. Thus, we build more cars and more freeways and wait in traffic like a bunch of dumbasses stuck with backward sucky technology that has outgrown its usefulness. Yet most people just accept it as-is because it's what everybody is used to. (Yes, there's public transportation, but it has the loss of privacy and you have to deal with occasional unwanted interactions with weirdos (who are often smelly and mumbling about type associations)).
** ''Could you show specifically where existing writing on "types" has been crappy?  I'm afraid a general indictment of writing style, on a general topic, does not help us improve it.''
** Didn't you agree that the PHP type docs were lacking?
** ''The online PHP manual is notoriously poor in numerous ways.  Therefore, I'm inclined to disregard it as characteristic of technical writing in general, or technical writing about types and language TypeSystems in particular.''
** At least we agree that the PHP type doc is poor. What about the on-line JavaScript doc? Do you have an opinion on that?
** ''Which on-line JavaScript doc?''
** Pick that which you find the "best".
** ''Were you not referring to a particular one?''
** I don't want you to bitch that I picked the "wrong one".
** ''Why don't you pick the one that '''you''' find clearest, but still flawed.  That way, we can meet half way.''

* And it's best to define "numeric string" before casually mentioning it.
* ''In a manual intended for beginners, that would be reasonable.  Here, I think it reasonable to assume readers know what a numeric string is.''
* And the apparent contradiction should be explained (or cleaned up) since "numeric string" is TWO types, not one in colloquial-land. Why even have (or rely on) a vocabulary that does that? It's just asking for confusion.
* ''That's why my description at the top of TypeSystemCategoriesInImperativeLanguages explains that values of different types can be encoded in each other.''
* You don't explain specifically what "encoded" means and where (in XML) such "encoding" happens. Yes, typical developers may have a general fuzzy notion of "encoding", but it's not specific enough for explaining/modeling type-related subtleties.
* ''I do explain what "encoded" means via examples at the top of TypeSystemCategoriesInImperativeLanguages.  The XML only models variables and values, not operators.  Encoding, if any, is recognised by operators.  Thus, it is a characteristic of operators, not values.''
* Okay, but do notice that you are using examples to "explain" encode. That's fine with me as long as it's allowed on both sides and you are willing to clarify if asked for specifics (including a specific model that may not necessary mirror actual implementation, but still "works").
* ''I thought examples would be particularly resonant, given that programmers are inevitably familiar with the concept, whether they've known it by name or not.  As for "a specific model that may not necessary [sic] mirror actual implementation", I'm not interested in distorted reality or technical fiction.  ComputerScience and SoftwareEngineering do not benefit from using lies as a substitute for understanding.''
* Like I said many time, the colloquial notions of types are usually fuzzy and overloaded. I know you disagree, but I'm basing my decisions on my view of reality, not yours. I disagree with the "mirror implementation" stance also. Implementations can change or vary for machine efficiency improvements or vendor choice and should not be the primary reference source for models used by programmers for apps if cleaner models are available even if they don't mirror actual implementation. A simpler UsefulLie may be better than a complicated truth. Again, I'd settle for epicycles if they were simpler than Newton's equations if the primary goal was to mirror the position of the planets rather than explain underlying movement mechanisms. Programmers mostly care about I/O, not interpreter implementation. I know you disagree with that also. So be it.
* ''What's a "mirror implementation"?''  
* ''It's true that a simpler UsefulLie may, in some cases, be preferable to a complicated truth.  It's not clear that this is one of those cases, nor is it clear how your "tag model" is simpler than the descriptions at the top of TypeSystemCategoriesInImperativeLanguages.  Just going by the sheer volume of descriptive text on TypeTagDifferenceDiscussion compared to TypeSystemCategoriesInImperativeLanguages, the "tag model" seems more complex rather than simpler.''
* TypeSystemCategoriesInImperativeLanguages is poor in my opinion. For one, it uses type-based polymorphism but does not model the mechanism for that type-based polymorphism. You '''dump one high-level issue onto another high-level issue'''. And, you have been in academics too long to judge "more complex" from the perspective of a non-academic. You think and write "funny". And volume of description is not necessarily a good measure of "complexity". Descriptions can be short and useless/confusing also. Anyhow, let both models exist and LetTheReaderDecide which model they want to use. Done. No more bickering.
* ''"Type-based polymorphism" is described in the "operator invocation" section.''
* Not well. You need to show, not tell.
* ''Whether it's done well or not is a matter of opinion, though it does include examples, so it does "show".  As such, it '''does''' "model the mechanism for that type-based polymorphism."  Your accusation is therefore unfounded.''
* No it doesn't. It ''uses'' type polymorphism, it does not MODEL type polymorphism. You explain complexity using complexity.
* ''How would you "MODEL type polymorphism"?''
* Polymorphism is an operator-level implantation detail. It's below what a model has to directly implement.
* ''Why do you think so?''
* Why ''should'' it be a requirement? That appears to be arbitrary to me. If you claim it's required, then justify that claim.
* ''What do you suggest as an alternative?''
* In my model I leave that up to the model user. They can implement their model of a given operator as they please (assuming it matches actual language behavior). I see no reason to dictate that as a requirement. Algol existed before OOP did, I would note.
* ''This is not about implementation.  My descriptions are conceptional, not an implementation strategy.  Operators like '=' were semantically overloaded in Algol regardless what mechanism was used to implement it.'' 
* The purpose of the model is to be able to build a '''runnable''' emulator of key parts of the language. You don't make/describe the leap between conceptual and runnable.
* ''I suspect my descriptions are a lot closer to "runnable" -- especially as the process is detailed -- than your "leave that up to the model user".  Indeed, it is trivial to implement the type-based polymorphism that I've described.''
* As an ''implementation suggestion'' for matching specific languages, that's perfectly fine. I give implementation examples. But to make that THE model is presumptuous.
* ''Can you think of an imperative programming language that it doesn't fit?''
* Why does that matter? If there are 20 ways to do something, that fact that technique #13 can do it does not make #13 a canon or THE right way.
* ''Whilst I make no claims that the "operator invocation" section is canonical per se (though the rest of TypeSystemCategoriesInImperativeLanguages certainly is), until the "operator invocation" section is shown to be flawed -- i.e., does not accurately describe some popular imperative programming language -- I see no reason to remove it.''
* Canon-ness is the key issue here, not "flawed". I never claimed it "flawed" (although it may not handle complex "dispatching" well). Uniqueness is the subject of concern, not "broken". And you have given no evidence the other part is a canon. 
* ''By "complex dispatching", do you mean PredicateDispatch or MultipleDispatch?  PredicateDispatch is indeed the generalisation, but it isn't used by popular imperative programming languages.  MultipleDispatch can be handled by the approach.  As for the rest being canonical, I've given you links to DateAndDarwen's work, as it goes to particular effort to clarify the distinctions; other ComputerScience texts will provide equivalent descriptions.''

''As for "when the association occurs, when it goes away", your phrase "has a tag" or "is associated with a tag" offers no more information about that than "has a type".  The usual assumption about models is that unless stated otherwise, we can safely regard an association as existing in perpetuity unless stated otherwise.  For example, in a model that refers to a set V {a, b, c}, we can assume a, b, and c have been elements of V since the beginning and will always be elements of V, unless it is explicitly stated otherwise.''

* So if one wants to find that "otherwise" to answer a question, they have to go digging in pages and pages. Not good document design. (I don't expect the reader to rely on just words for the tag model.)
* ''That's a documentation problem, sure.  I'm not clear how bad documentation is fixed by a "tag model".  As for relying on words, that's why we have diagrams.  Even better, that's why we have formal notations that eliminate ambiguity in both verbal descriptions and diagrams.''
* The tag model solves such by using familiar data structures with known quantitative rules, and results in explicit algorithms for changing the data structures. '''It's more like machine language or BASIC than math''', and thus very "mechanical" and explicit such as "check to see if attribute X contains character Y, and if it does, then change attribute Z to 'foo'". There's no abstract math or math symbols or reference-heavy vocabulary (definitions that depend on other definitions that depend on yet other definitions). I don't dispute that there are math-like notations that may be more accurate and compact than English alone, but most developers are not going to relate to those (either forgetting them since school or have never been sufficiently introduced to them). Familiar data structures plus explicit BASIC-like or machine-language-like data structure transformation rules are the best solution in those circumstances. KnowYourAudience. You will likely dispute this, but for the sake of argument even if most would be comfortable with a math-like explanation or an English-centric explanation, you couldn't realistically claim that ALL will be, and thus it's possible that 1% or so may just like the tag model better.
* ''Where are your "familiar data structures" and "explicit algorithms" documented?''
* TypeTagDifferenceDiscussion gives examples. If any are not clear enough to you, I've already agreed to refine them in terms of StepwiseRefinement. (Remember, the exact algorithms for any language model depends on the specific language such that selected representative examples are given, but the details will depend on a given language.)
* ''I re-read TypeTagDifferenceDiscussion, and I do find it unclear.  It's lacking introductory text to give the explanations context, and the explanations themselves appear disconnected.  They're mainly disjoint pseudocode examples with rambling discourse on their meaning, rather than presentation of a cohesive model.  I can find no "familiar data structures" or "explicit algorithms".  It appears the model exists in your mind, but hasn't yet made it into a written document.	TypeTagDifferenceDiscussion appears to be the discussion and illustrations that would normally follow presentation of a model, but that presentation is absent.''
* XML is not a "familiar data structure" to you? I agree it needs a better intro, but it would be repeats of stuff I've written already elsewhere, probably multiple times, and you'd likely launch the same complaints about it. If it's not clear to you, I'm not sure what to do. I don't know where the trains in your head are derailing because I cannot directly view your train yard.
* ''XML is a familiar markup language.  I've never heard XML described as a "data structure" before, familiar or otherwise.  Familiar data structures are binary trees, linked-lists, stacks, queues, doubly linked-lists and arrays.''
* Is "common data representation" sufficient?
* ''As for an introduction to TypeTagDifferenceDiscussion being "repeats of stuff I've written already elsewhere", it is precisely the lack of introduction '''and''' the need for the reader to self-assemble your model from multiple pages that makes it difficult to understand and impossible to appreciate.  If you were to describe it in '''one place in its entirety''' -- say, in TopsTagModel -- even if there's duplication, at least we would have a definitive source to refer to.''
* I pretty much doubt that.
* ''You doubt that we would have a definitive source to refer to if you described your model in one place?  Huh?''
* However, let's try this for now: Are the explanations/mini-models for the ''specific'' observations in TypeTagDifferenceDiscussion clear to you?
* ''No, I find them unclear.  I can understand what you're trying to say, but I find the descriptions awkward, overly-verbose, inclined to ramble, incorporate extraneous detail that is often unenlightening (the proliferation of W^s and R^s is baffling, for example), and ruminations on things like "how we get two 'types' at the same time" are gratingly contrary to what I consider simple, direct, and fairly obvious explanations.  Overall, the whole set of explanations (they are mini-models?  what's a "mini-model"?) lack the elegance and simplicity of a model, and instead seem like an arbitrary collection of disjoint observations that share only some coincidentally similar terminology, but are otherwise the result of misapplying art critique to elementary ComputerScience and SoftwareEngineering.''
* Redundancy is the least of our problems. In fact it can be argued that redundancy is sometimes good for explanations because presenting the same info in different ways may help it click and/or be reinforced in somebody's mind; somewhat comparable to studying the same physical object from different angles. Anyhow, let's put cleaning up redundancy as a low priority because so far the biggest bottleneck is clarity. Redundancy is an annoyance at best but lack of clarity is a show-stopper.
* ''I didn't mention redundancy.'' 
* So writing style aside, are they clear and if not where and which part is not clear? Where do reinforcements need to be added? And why are the W and R "pointers" a problem? I like those kinds of things in documentation because they help my WetWare by labeling and pointing to things to make sure I'm looking at the right thing in terms of the description. Arrows with labels are usually a good thing in my book. And making it double clear what's being read versus what's being written to is also a good thing in my book. English is sometimes either ambiguous, or perhaps I have a language weakness in my head that makes it ambiguous to my WetWare, but I don't think I'm alone in that regard. Arrows with summarizing labels and attributes are things I prefer in most documentation. (Granted using ASCII limits our options, but we can still point and label to some extent.) If arrows irritate you (for reasons unknown to me), I'm sorry, but you are not the ideal reference specimen. Think of them kind of like the "program pointer" in machine language where the "current instruction" is identified via an address. The machine language description often specifies the specific address being read/changed at a given time and the rules/algorithm for changing the various bytes. It's more of a "mechanical" view of the processing rather than a linguistic one. We can apply StepwiseRefinement on such rules/descriptions/algorithms to build an actual machine language interpreter if needed to fully illustrate/mirror/model the process in an unambiguous way because it's in C or Pascal or the like instead of English. '''If English was good enough, we wouldn't need Pascal, C, etc.''' (COBOL? :-)
* ''Writing style aside, they are not clear.	I have no objection to defining a language, structures and operators in order to create a model.  That, in fact, would be excellent.  That is not what you've done.  Your "machine language description" is entirely unlike machine language.  Where are the operators?  What are their operands?  Etc.''
** Let me re-phrase that. It doesn't have to be a machine language, per se, it can be a pseudo-code snippet of an interpreter to process the target operator being modeled. An Algol-like pseudo-code notation that operates on model data structures/notations is familiar to most programmers and is usually pretty clear to them. Again, if English was good enough to explain processes, we wouldn't need computer languages. '''Computer languages were created for the very purpose of describing processes.''' Programmers have to know imperative algorithms and data data structures to do their jobs, but not necessarily have a strong grasp of English. Thus, it's not rational to lean toward an English-centric model. If your target audience was literature majors or lawyers, then an English-centric approach may be more fitting.
** ''All fine, and that's why we have diagrams to supplement English text and notations to replace English text.  Indeed, a language or pseudo-code (which, if done right, is just a language without an implementation) can be an excellent notation for expressing the workings of a system or model.  However, I have not yet seen an indication of this in your "tag model" descriptions.  I've seen pseudo-code used for observations, but not for explanations, and certainly nothing that I would consider essential to being a model: parts and rules for combining the parts.  Your "Observation x Modelling" descriptions on TypeTagDifferenceDiscussion consist only of XML illustrations with English descriptions and one pseudo-code assignment to a variable.  Describing these via a clearly-defined purpose-built language would be excellent.''
** Which example do you want refined into more specifics? Please select one.
** ''How about "Observation 4 Modelling".''
** Alright. I'll draft something up.....soon. Note that the result will resemble the style of snippet 4792 on TypeSystemCategoriesInImperativeLanguages. Thus, if you are bothered by that style, please let me know early.
** ''If you're going to use pseudocode, that's fine, but please identify the operators that you're going to use and what they do.  It's not clear how the pseudocode is related to the XML above it.  I would expect a clearly-defined, finite collection of structures, plus operators that make reference only to the structures.  Imagine that you're building a type-illustration virtual machine.  What does the machine look like?  What are its parts?  What operators manipulate the parts?''
** Agreed. I thought the written steps already made that clear with labelled and text-referenced lettered pointers etc. but apparently that wasn't clear enough to you. The pointers appeared to confuse you more than they helped for reasons that honestly and truly baffle me. You have an odd mind and think very different from how I think.
** ''Here, what I'm simply looking for are data structures and the code that manipulates them, just like any program.  If that's "odd", so be it.  Program source code can be as rigorous as any formal notation.''
** I thought I provided that info. Apparently you read it differently than I do. Thus, time for plan B.
** ''Where did you provide it?  Perhaps I missed it.''

* And "why can we seemingly have multiple types at the same time" is a likely question a reader would have and should be addressed directly and clearly in my opinion. The apparent contradiction between typeName-like functions and is-type-X-like functions, for example, should be addressed and illustrated face on.
* ''Sure, but it's trivially explained:  If a value has a type, then typeName-like functions return the type name whilst is-type-X-like functions examine the value to see if it encodes type-X.  Simple stuff.'' 
* You haven't clarified the specific mechanism of "encode", and make sure its clearly separate from has-type-ness.
* {Why would we care about the specific mechanism? However, the separation is already clear. The language defines a type system. That type system determines what values are associated with what types. On the other hand, when you map values of one type to values of another type, that mapping is an encoding.}
* We need a specific model; otherwise it's English Fuzz. And, no the separation is NOT clear. Yes, I know the language defines the type system, but we have to model that type system (or relevant parts of it) SOMEHOW if we want to predict its behavior. There's no magic shortcut. And you have not defined/described what exactly is being mapped or even how we check to see if mapping took place. What exactly is being mapped to what and how do we empirically verify/see that? Yet another overloaded/vague word: map. We need another one of those like a hole in our cotton Jello Cloud. Either your English comprehension is so very far above mine, or you are just plain '''caviler with English'''.
** ''I think you mean, "cav'''a'''l'''i'''er with English". <irony/>''
** He he he, how embarrassing. Overhaul the fucking written language with a phonetics system, but too many will defend the existing screwy approach out of love of stupid tradition, just like types. 
** ''That seemz reeznubl, but givun owr familee-aritty with English spehling, dooing sowe onlee maix it hard too reed.''
** QwertySyndrome
** ''There's a difference.  We may be stuck with a keyboard layout by convention, but we use conventional descriptions of TypeSystem implementations because the descriptions describe how languages actually are built and how languages actually work.  It's not a matter of pure convention, but pragmatic convention that serves a purpose of describing actual systems.''
** Like I keep explaining, a typical developer only wants predictive ability from a model/explanation and doesn't care how the fucking interpreter is actually built. '''Stop solving the wrong problem.'''
** ''Fine, but in the absence of any evidence that your "tag model" is simpler or easier to understand than conventional explanations, and given that a differing explanation creates a communications gap between those who understand only the "tag model" vs those who understand how programming languages are built, what justification is there for having a "tag model"?''
** I'll leave the on-going debates about "simpler" out of this section. But it is possible that part of the big problem with type documentation is that the metaphorical '''car engineers are writing the "drivers manual"''', and that's often a recipe for communication disasters. If you've ever seen end-user documentation written by tech master degree holders fresh out of college, you'll have some idea of what I mean. Implementation-centric viewpoints or assumptions leak into the interface-user side of things.
** ''Your speculation about documentation is noted.  My point still stands.''
** Catering the doc to the interpreter makers is relatively unimportant. Yes, such may create a communication "gap" between the two parties, but '''so what'''? Is that connection really that important that we have to make models more complex to keep that channel fully open? (Yes, I know you disagree that such a simple-versus-complex choice is actually here, but consider the hypothetical at least.) I'm not dismissing your concern, only saying it's the smaller of two evils.
** ''It isn't a matter of catering documentation to interpreter makers, but whether or not the simplified model is actually simplified, which it appears not to be.  What parts of your model are actually "simpler"?  And do you really expect your model to be adopted in favour of conventional explanations?''
** I already explicitly told you I'm not going discuss the simplicity issue HERE. Why do you blatantly ignore that? You are really pissing me off.
** ''Why do '''you''' ignore the simplicity issue?  It appears to be crucial.  If your model isn't simpler whilst still covering exactly the same considerations, what's the point of having it?  And why are you reacting emotionally to text on your screen?  If it bothers you that much, go walk the dog and cool down.''
** I don't ignore it; your metric for "simplicity" is fucked up.
** ''How so?''
** Further, it's not just about simplicity, but leveraging existing communication knowledge/styles. Like I said above, imperative algorithms and data structures are already familiar to programmers (as a job requirement) such that if we can ride that train for our documentation, then communication will be better.  Your approach is too different from that requiring a potentially unfamiliar communication style. (Actually, I think it's garbage, but am entertaining the idea that it's clear only if one "gets it".)
** ''But your model has no imperative algorithms and only one "data structure", a tuple shown using XML.  What algorithms and data structures do you mean?  Are you saying you think imperative language TypeSystems are garbage?''
** I have too shown imperative algorithms. They are not just fleshed out very specifically yet (in progress). As far as the actual type systems that run most interpreters, like I said and justified many times, mirroring the actual mechanism is of secondary importance to grokkability by typical developers (or at least a subset who don't like the traditional verbal-oriented approach). If epicycles satisfy ''those'' goals/priorities better than Newton's work, I'll go with the epicycles. Most developers only need to predict the position of the planets, they DON'T need to explain them. Is that clear???!!! (Ideally languages should be defined by their I/O profile, not implementation anyhow.)
** ''So you've "shown imperative algorithms" but they "are not just fleshed out", i.e., you haven't shown them.  I guess you've imagined them.  When you've shown them, then we'll see.  So far, it appears that for those aspects of language behaviour that your model accounts for, it's equivalent in complexity to the conventional explanations, but with odd terminology ("tag") and at least one outright error -- variables in dynamic languages do not have types, only values do, which is why dynamically-typed languages are sometimes called "value typed".  Note that despite the apparent intuitive observation of epicycles, they actually make it more complex to calculate planetary positions than Newtonian or classical mechanics.  Your defence of them is odd; why do you wish to defend flawed models?''
** I'll leave the objective existence of values debate to TypeSystemCategoriesInImperativeLanguages. Also, I did not say that epicycles WERE better, but rather IF they were better. I was making the point that '''a model useful for a specific purpose CAN be better than general purpose model''' in some cases/uses. As general principle I think you will agree. Being closer to "reality" (implementation) is not necessarily the most important concern. A better actual example may be Newtonian physics versus Einsteinian physics. Technically, the latter is more accurate, but may be more difficult to use as a tool. 
** ''I don't disagree that a simplified model may be useful for a purpose.  We already simplify the conventional explanations by not talking about various optimisations.  However, you've yet to show that your "tag model" is better suited to its purpose or simpler than conventional explanations.  So far, the only evidence of "simpler" appears to be that it covers fewer cases.  How is it simpler at describing the same behaviours?  And we're not dealing with a significant difference in calculation complexity that are only significant (for most purposes) at highly particular endpoints of a system (i.e., where elements are very small and/or very fast) like we are with classical mechanics vs special relativity.  Your "tag model" appears to deviate from conventional explanations in such minor details that I find it difficult to justify any claim that it genuinely results in notably less effort to determine results or explain language behaviour.''
** Fewer cases? And it's "less effort" because it uses a communication technique already familiar to most developers because it '''uses communication techniques that are necessary for their job'''. You CANNOT make the same claim, because you rely on subtleties of language and verbal meaning. I believe it to be vague, but you insist it's clear. If it's "clear" I don't "get it" then, and many developers are not native English speakers such that their "get it" likelihood is even lower than mine. Thus, rational pro/con analysis dictates use what they have to know to get a pay check when designing explanations.
** ''You're referring to your XML diagrams?  I've illustrated the conventional model with XML at the top of TypeSystemCategoriesInImperativeLanguages.  So, you can't use that as a distinguishing characteristic.  You've explained your model using English text; even more than I used at the top of TypeSystemCategoriesInImperativeLanguages.  So, you can't claim that your model is easier for non-English speakers to understand.''
** No, it's not just the XML. It's imperative code (pseudo-code) that operates on the XML. It doesn't have to rely on English because it's taking inputs like a program, processing them via imperative code, and producing output. We try to use English as a handy shortcut, but potentially StepwiseRefinement could produce a runnable interpreter if we bothered to flesh it out all the way. In that case one wouldn't have to know a lick of English to follow what that model is doing.
** ''In TypeTagDifferenceDiscussion, in the areas that I assume describe the model -- Observation <x> Modelling -- I can only find one line of pseudo-code that appears to operate on the XML, 'b = "123";'.  The remainder appears to be English text.  Is there more that I've missed somewhere?''
** If you see an ambiguous statement, point it out close to where it actually is.
** ''This isn't about the ambiguity of statements.  You claimed your model is "imperative code ... that operates on the XML" and "[i]t doesn't have to rely on English because it's taking inputs like a program, processing them via imperative code, and producing output".  Apparently, none of that is the case.''
** Are you asking for clarity here, or non-English?
** ''You write that I "can't claim [my] model is easier for non-English speakers to understand", but you apparently can't claim that either.  You claimed my model relies on subtleties of English, implying yours does not.  Apparently, it does.  You claimed your model is "imperative code ... that operates on the XML" and "[i]t doesn't have to rely on English because it's taking inputs like a program, processing them via imperative code, and producing output", but there's no evidence that it does so.''
** Let me try to re-explain it this way. There is a hierarchy of detail using StepwiseRefinement:
*** 1. Write the imperative transformation steps in English. If that is not clear to the reader then:
*** 2. Write the imperative transformation steps in pseudo-code. If that is not clear to the reader then:
*** 3. Write the imperative transformation steps in runnable code. If that is not clear to the reader, then fire them because they don't qualify to be a programmer.
** ''So you're still at step 1, but you're claiming you're at step 2?  Is that right?''
** Where did I claim I was at step 2? I gave a reference to a quick example of 2.
** ''You claimed your model is "imperative code ... that operates on the XML" and "[i]t doesn't have to rely on English because it's taking inputs like a program, processing them via imperative code, and producing output", yet there appears to be exactly one line of that.  The rest is English text.  Hence, you're at Step 1 but '''claimed''' to be at Step 2.  Why?''
** Where did I claim I was already at step 2?
** ''You claimed that your model is "imperative code ... that operates on the XML" and "[i]t doesn't have to rely on English because it's taking inputs like a program, processing them via imperative code, and producing output", which implies Step 2.''
** I was hoping describing an imperative algorithm would be good enough to communicate the algorithm to YOU. Apparently, it's not.
** ''Describing an imperative algorithm would be fine, '''if it actually existed.'''  It doesn't, but you claimed that it did.''
** It looks like one to me. If you interpreted them some other way, I apologize. There is no intent to deceive. It's obviously we have a difficult time communicating with each other. It looks like we'll just have to keep moving down the StepwiseRefinement ladder.
** ''I'm certain you didn't intend to be deceptive, but I do find it curious that your use of terminology -- such as what you consider to be an imperative algorithm or not -- is so different from mine.  I would expect an "imperative algorithm" to have steps, probably numbered, that one could follow in sequence.  What do you consider it to be?''

* {What's wrong with using the type system as defined by the language? Why would we need to model it with something else?}
* Are you seriously asking me that yet again? Sigh GroundhogDay. '''For the sake of argument''', suppose a fair percentage of developers did find your writing style and that of your favorite type authors "difficult". With that situation as the premise, what would be your Plan B?  -t
* {Study them to figure out what they do understand and then build on that until they can understand what actually happens.}
* You are stubborn.
* ''No, he's correct.  We have a term for the process he describes.  It's called "education".''
* No, it's called stubborn adherence to tradition, or bias toward over-paying for specific knowledge, which I suspect your pockets personally grow from. I don't have a financial horse in this race. FUCK TRADITION that doesn't carry its weight.
* ''It's not tradition we're advocating, but explanation of how languages work using accurate descriptions of how they work.  So far, there's no evidence that your "tag model" makes TypeSystems in popular imperative programming languages easier to understand -- or even makes language behaviour easier to understand -- so there's no justification to deviate from explaining how TypeSystems actually work using conventional terms.''
* I've already explained why matching actual interpreter implementation is of secondary importance to model simplicity, and won't repeat that argument yet again repeatedly multiple times redundantly. (It's almost the same as your model anyhow, but you just surround yours with confusing writing.) What I'm doing is (attempting to) leverage the '''existing knowledge and familiarity''' of typical developers: imperative algorithms and data structures (or XML), to create language- and operator-specific models. 
* ''How does the term "tag" leverage the existing knowledge and familiarity of typical developers?  Where are the steps in your imperative algorithms?''
* I don't know why you are seemingly obsessed with that. It could be called a "plizzle" and the model would still work. The labeling of the parts of the model is a minor issue. If there were existing terms that were not overloaded and confusing or vague, I'd consider borrowing such, but so far have not found a better candidate(s), as we've discussed probably at least half a dozen times already.
* ''I'm "obsessed" with it because it's blatantly incorrect.  Values and variables don't have tags, they have types, and understanding types is fundamental to being a programmer.''
* "Have" types is blatantly vague and overloaded.
* ''It's colloquial, but sufficiently idiomatic to be instantly recognised among those who have made even a negligible effort to understand values, variables and types.  I'm assuming that's the case here on WardsWiki.  If I were writing an introductory textbook for 1st year undergrads, I'd go to greater effort to explain what a "type reference" is and how every value has one.''
* I place clarity above vocab familiarity.
* ''How is "has a tag" clearer (or, indeed, even different from) than "has a type"?''
* You've asked that already, and I'm going to give you same answer: The model/kit is intentionally '''designed to NOT depend on the term'''. I don't want the model to depend on interpreting English (other than the basics) because English sucks as a technical description language. We could call it the Twizzledoodle, and as long as it's consistently referred to by Twizzledoodle in the model (modeling kit), it doesn't really matter. The visual of a "tag" like you find on store shelve products or underwear happens to be a nice visual reference in my opinion (okay, maybe not the underwear), but that's just a bonus. "Types" is overloaded in colloquial-ville for typish-like behaviors often found in dynamic language land, "tag" is not.
* ''As long as you use "tag" where "type" is conventionally used (and, I would argue, obviously belongs), your model is going to cause confusion and be rejected here and elsewhere.  The so-called "typish-like behaviors" are almost inevitably types and should be identified as such.''
* I'm weighing one kind of confusion against another, and "type" loses for reasons already given multiple times repeatedly.
* ''The reasons you've given can all be interpreted as your personal preference.  Do you have objective evidence of "type" being inherently confusing or overloaded in a manner that inevitably causes confusion?''
* We've been over this "common notions" thing many times already. Neither side has anything other than anecdotes. Give it up, dude, it's a dead horse.
* ''I've not asked you about "common notions".  I've asked you specifically to provide objective evidence that there is something confusing about the use of the term "type".  Can you show an example of a potential confusion, whether from overloading or otherwise?  For example, you should be able to identify sentences like, "Therefore, a set is not used effectively." and show that the sentence makes reasonable sense whether you interpret "set" to mean a noun (a collection of elements) or a verb (to alter a property) -- hence it is overloaded -- and it is therefore unclear which meaning is intended, and that this potential confusion happens frequently enough to matter.''
* The cfArgument example was such an example, and so is the contradicting nature of typeName() versus isTypeX() functions, and the potential plurality of isTypeX() functions ("being" multiple types at the same time). In a general sense, dynamic languages let each operator determine what "type(s)" a thing is such that to say object X "has a type" Y is misleading because it's not the object that determines the "type", but the operator (if it can even be defined). However, the object X potentially has type-related info associated with it, and the operator may or may not use that. What I call the "tag" is not necessarily "THE" type, but rather provides type-related info that a given operator can use IF it wants to. There are multiple aspects "associated with" an object that may affect what "type" the operator sees in the object. The tag may "affect" what the operator sees as the type, but it is false that it always "is" the type that a given operator "sees". You might walk into my country with a police badge from your country and say the badge makes you a "peace officer". However, my country may choose to ignore that badge and instead check to see what kind of underwear you are wearing or who your dad is in order to qualify you as a "peace officer" in my country. Thus, to say you "are" a peace officer is misleading or wrong: it's relative to the country (operator). There is no universal "is".  And you may be "associated with" a badge, but that may be meaningless in a given country because that country may not use or care or recognize that "associated with". Your badge is ignored in some countries: it's existence on your shirt is meaningless. Thus the answer to whether object X "has" or "is" type Y '''is relative'''.
* ''Again, you've identified the aspects to which you object, but have not identified an actual confusion.  For example, to sustain the argument that there is a "contradicting nature of typeName() versus isTypeX() functions", you'd have to show that there is an irresolvable contradiction, e.g., a case where "x == y" in one place and "x != y" in another.  That does not appear to be the case here.  Here, it's the case that typeName() always returns the name of the type associated with the value; isTypeX() returns true if the named type equals the type associated with the value or if a value of the named type is encoded in the value, otherwise it returns false.  That's not contradictory.  It's perhaps not particularly elegant, but that's a PHP quirk, not a problem with the term "type".''
** Those are just words; they don't mean anything concrete to me. You might as well say, "typeName returns the zigs of the snoobs from the glibbles, while isTypeX() returns snorks from the grommit if it's Tuesday, otherwise returns the floog of the niff's gumple." They don't have to be contradictory to cause communication problems. They can cause problems by being too vague to mean anything concrete. In other words, "contradictory" is not the only possible problem they can have. As an extreme example, "Bakt alk asd asdfuehs asdf asdrra akbk;s" has NO known contradictions, but it's obviously not very useful in terms of conveying meaning and clarity (except maybe to you Orionoids).
** ''What you call "just words" presumes you are familiar with fundamental ComputerScience notions about programming languages: a literal (a string of characters) denotes a value, every value is of a type; every type has a name (e.g., 'string'); and every string (a value of 'string' type) can encode literals of various types.  E.g., "123.32" is a literal that denotes a value of the type named 'string', which encodes a literal -- 123.32 -- that denotes a value of a type named 'float'.  Thus, an operation like typeName() simply returns the name of the type of "123.32" ('string'), but an operation like isNumeric() parses the string "123.32" to see if it encodes a literal of some numeric type and returns true if it does.''
** They are not well defined. "I know 'em when I see 'em" doesn't always cut it.
** ''But they are well defined.  Look in ComputerScience and ComputerArchitecture textbooks, and articles like http://lucacardelli.name/papers/onunderstanding.a4.pdf  You're probably not going to find any single source that covers precisely what I did in such a succinct manner, but you will certainly find that the references, taken in totalis, agree with what I wrote.  Anyway, I should think terms like 'literal', 'character', 'parses', 'value', 'string', 'numeric', 'encodes', 'float', and 'denotes' would be self-evident, given their meanings here are consistent with their usual English use in general and ComputerScience in particular.  'Type' is not defined here, but doesn't need to be, here.''
** IF they are well-defined somewhere, they are not in a form digestible to non-academics. And English is vague, as the above illustrates. See PageAnchor human_languages_26
** ''PageAnchor human_languages_26 highlights the value of formal or semi-formal notations in eliminating ambiguity.  Would you prefer that I describe the above in a formal or semi-formal notation?  Oh, wait, I already did.  It's at the bottom of TypeSystemCategoriesInImperativeLanguages.  Whilst the Cardelli paper is somewhat academic (though very readable, like much of Cardelli's output), undergraduate textbooks are usually not academic.  Furthermore, the majority of university ComputerScience or SoftwareEngineering courses will spend their first few weeks of introductory programming on comprehensively (though informally) defining and demonstrating what literals, variables, values, types, strings, characters, "numeric" and expressions are.  That's what the early days of programming are all about, at a time when formal or semi-formal notations are as unfamiliar as the programming concepts (and language) that the beginners are learning.''
** Your model is A model, not necessarily THE model. This is right back to the ol' "canon fight". And the material in a typical classroom is vague. You even agreed that each language ultimately gets to decide what is called what on a per language basis (at least in the vendor's docs). You should have anticipated my responses here. We've been over these multiple times. Please try to remember better so that I don't have to repeat my responses.
** ''I'm not presenting a model.  I'm describing standard introductory ComputerScience material using conventional terminology.  Individual languages do get to define their own terminology, or misuse it (*cough*PHP*cough*), but descriptions about the foundations of programming languages -- in introductory ComputerScience terms -- have conventional terminology.''
*** Bull. Keep claiming it all you want. Claims nor repetition makes truth.
*** ''You're right, claims and repetition don't make it truth.  It's already truth.  See introductory ComputerScience textbooks.''
*** I did. You are wrong.
*** ''Obviously, you didn't.  Either that, or you found one unusually dire textbook.  This is first-year, introductory programming language ComputerScience material.  First-three-weeks of first-year, really.''
** "Conventional terminology" is ambiguous. It's only non-ambiguous if somebody defines such terms PER LANGUAGE (which may still may be ignored during colloquial conversations or by non-vendor authors.)
** ''The context is popular imperative programming languages, in which the conventional terminology is not ambiguous.  The term "literal", for example, has the same meaning no matter what popular imperative programming language we're talking about.  There may be variation in the syntax of certain literals and what types they map to -- that is certainly language-specific -- but the concept of "literal" is consistent.''
** No, sometimes developers call literals "values". But even if SOME terms were stable, that doesn't mean all is.
** ''Yes, sometimes developers call literals "values".  That's because literals '''always''' denote values, so it's a handy shorthand to call literals "values".  However, such use of terminology does not mean conventional terminology is ambiguous, it only means one should be aware of the usual terminological shortcuts.''
** A light does not switch on at people's foreheads when they are using shortcuts. It's all used in a big fuzzy pot of approximation. You can't cherry pick which statements you call "shortcut" and which you call "accurate" to make your case because it is you doing such classification, not the speakers.
** ''It doesn't matter whether people use "value" with full understanding of the fact that they're using it as a shortcut for "literal denoting a value", or whether they merely see a literal and think "value".  Either way, they're effectively looking at a value.  But you're right, it's me making "doing such classification" -- though it's actually ComputerScience that has defined the distinction -- between "literal" and "value", because it doesn't matter whether programmers do or not.  We're trying to effectively describe language semantics, aren't we?  Not capture programmer misconceptions?''
** Re: "We're trying to effectively describe language semantics..." - Well, it's not working.
** ''Where is it not working?  Is there a semantic related to variable assignment (which is mainly what we've been talking about) in a popular, imperative programming language that is not described by TypeSystemCategoriesInImperativeLanguages?''
** Arrrrg. Again, Mr. Forgetty, that's '''one of many ways''' to model behavior related to variables. It's not a canon of semantics or a canon of fucking anything else. 
** ''If it's "one of many ways to model behavior related to variables", how does that mean it's "not working" to describe language semantics?  There may indeed be many possible ways to interpret behaviour related to variables, but the one I've described is the only one that ComputerScience has settled on as definitional -- and for a long time now.  These issues were settled before the first digital computers were built, because settling them was necessary to designing the first digital computers.  By the way, is your rude language necessary?  If you have to resort to vulgar language to make a point, it instantly calls into question both your credibility and your confidence in your own answers.''
** It's because I'm getting frustrated at your repetitious bullshit. '''THERE IS NO CANON! You are a false prophet and should be fired from that university. Closed-minded stubborn biased professors will ruin the next generation by filling their head with crap.'''
** {Really? Can you find any ComputerScience text that says otherwise? You won't because they all do it in the manner described. That is enough, right there, to make it canonical. So there most definitely is a canon. It's also not crap as it's been successfully used since 1967. It in turn, is derived from the formal semantics of logic, which has been successfully used since the 1930s. That came about because the informal semantics in use before then had proven to be insufficiently rigorous for mathematical use.}
** Arrrrg, again again again, if it's vague/ambiguous, it can fit MANY models. Falsification is a straw-man in fuzz-land. And "been successfully used since 1967" strongly suggests it's an implementation model. Our '''head models don't have to match implementation''' any more than we should force ourselves to think in stacks; but stubborn professors may start pushing that very idea if somebody doesn't put an end to these phony cannon and HOF claptraps. They want to make themselves worth more by endorsing complexity and confusion. It's selfish greed. Fuck these '''professional convoluters''', they are dangerous to the profession.
** {I'm not sure what the problem would be if it fit "MANY models". If falsification (one of the foundations of science as it is practiced today) is a straw-man, it's yours. You are the only one to mention it here. "been successfully used since 1967" doesn't suggest that it's an implementation model. Furthermore, I'm not talking about implementations at all, so none of that matters here. We also aren't talking about HOFs here. So that also doesn't matter. As for canon, it is canon for the simple fact that they rarely use anything else (to the point that I've never seen them use anything else). Your final rant is borderline paranoid. It's also hypocritical since you endorse a more complex system.}
** It's not more complex, you just claim it is because you are biased against me and/or mistake your favorite head models as the ideal of parsimony out of personal comfort. I don't know what you are talking in the first part. Perhaps I misunderstood what you meant by "Can you find any ComputerScience text that says otherwise?" Otherwise to what? They don't clearly contradict EITHER model.
** ''Your recent responses have been full of invective, crude language, and personal references which suggest you're taking this far too personally.  Perhaps you should leave this topic for a while and return when you're ready to discuss it rationally, calmly, and objectively.''
** I am capable of being objective and logical while cussing at the same time. Your repetitious forgetfulness and evidence-free insistence of the existence of canons is heavily wearing on my patience, however.
** ''You may be capable of being objective and logical whilst cussing, but you've yet to demonstrate it.  Don't confuse forgetfulness with what is actually rejection of your specious arguments.  If you're looking for evidence, you need look no further than virtually every introductory ComputerScience text, which are all sufficiently in agreement as to be effectively canonical.''
** As I read such texts, they ARE vague to me, as my mind processes and interprets English. In the past when we go over such text together and I point out multiple alternative interpretations (per everyday English usage), you say something along the lines of "if you read the fat stack of Computer Science books I have, then you'd JUST KNOW what they REALLY meant." Even IF that statement were true, for the sake of argument, it's not SELF STANDING ENGLISH as written per "regular" reader. It would be a PrivateLanguage disguised as a public language. Thus "has" may really mean "contained (nested) inside the data structure X", but the reader doesn't know that "has" is not really the ordinary "has" from everyday English, but rather an alias for the function tranformationFluxReductionRetainment33() or whatnot. It's like spy language where "it's raining at the house" really means, "Get your staff out of Stockholm immediately". Such books are then misleading, which underscores my original point that they are badly written (at least for non-MS/Phd's). If they are ONLY intended for academics, they should state so clearly up front. And still leaves no decent material/definitions for non-academics. Now you have TWO problems: lying and gaps. --top
** {Everyday English isn't rigorous enough to handle the needs of technical disciplines. That's whey every last one of them develops their own technical definitions and jargon. The fact that you are trying to attach everyday meanings to words with technical definitions would certainly result in the confusion that you obviously suffer from. Texts written using the technical definitions aren't misleading, and their authors aren't lying to you. You simply don't have the background to understand them. That gap can be bridged by having the interested non-academic learn what the technical terms mean. We refer you to "the fat stack of Computer Science books" in order to bridge the very gap in your knowledge that you are complaining about here. (BTW, it's not a PrivateLanguage since it is shared across the entire discipline and not just one person, as the page you linked to states.)}
** YOU implied they were clear enough '''as is'''. Now you appear to be flip-flopping. Do I need to highlight your own slippage verbiage? Nor have you proven that the academic material is intended as a canon, rather than just an implementation and/or modelling suggestion for academic exploration. And an "entire discipline" can still be a PrivateLanguage: it's private to that discipline. Other disciplines typically won't know or care. 
** And my goal is to find a definition and/or model that is clear to '''average developers'''. I don't give a flip about communicating to academics. Is that a bad goal??? If I have to give a model/definition that differs from the academic ones, so be it, '''as long as it works''' for intended purpose (provides sufficient predictive power). If they can digest epicycles better than Newton, so be it, epicycles it is. If I only need to model planet movements and not gravity, any UsefulLie will do. (With caveats about its limits stated to the user).
** {It is clear enough as is. That doesn't mean they are using everyday English. The two statements are neither contradictory nor flip-flopping. As for being canon, you've been told how to verify for yourself that it is. Your failure to do so is solely on you. And, no, an entire discipline cannot be using a PrivateLanguage. Look at the definition '''you''' linked to and see that it very clearly states that a PrivateLanguage is used by a '''single''' person. Entire disciplines, particularly ComputerScience, consist of more than one person. It is therefore, not, a PrivateLanguage. As for your goals, I really don't see the point. Judging from the people I've worked with and what companies ask for as qualifications when they hire developers, the average developer will have learned the ComputerScience terms by the time they start working.}
** In a rough notion-y sense, yes, I've agreed with similar statements probably 20+ times already. And it is ''not'' my job to hunt for and compile YOUR evidence for YOUR canon claims: YOU made the claim, YOU provide the evidence. Simple. It is my assessment that type-related material in typical textbooks and manuals is a very weak spot of IT, especially when it comes to dynamic languages. I've dissected the English in samples on this and related pages and I believe I've demonstrated sufficiently to the reader the kinds of problems found in such statements. If you think it's all fine and shiny, go ahead and live with that false impression. I honestly believe your bias makes you read with a jaundice eye to project your favorite definition/view into any English you encounter such that you don't recognize ambiguities and potential alternative interpretations. It's somewhat similar to my "proofreading problem" described in DocumentationAnecdote: my mind projects my intent into what I am reading back such that I have a hard time reading it objectively. However, your brain does that at a higher level of meaning.
** {It's not my job to cure your ignorance and pointing you to where you can find the evidence does qualify as evidence. However, I will give a link. http://en.wikiversity.org/wiki/Introduction_to_Programming/Variables  Notice, in particular, "In computer science, a variable is nothing more and nothing less than a named location in memory where data can be stored. In some languages, any kind of data can be stored in a variable while, in others, each variable is given a well defined type by the programmer and only data of the correct type may (or at least should) be stored in that location." You've already admitted to a flaw in the way you assess these things. You try to use the everyday meaning of English words when the technical meanings are the ones intended. That does result in a garbled account, but the problem is at your end, not with the us. (From my experience, you will sometimes even make up meanings that are neither the technical ones intended nor the everyday English ones in order to try and "win a point".)}
** That's NOT how one presents evidence for textual canons. Not even close. You are just being lazy and trying to hide your sin of sloth via red herrings. And your quotation only shows that there are multiple ways implement and handle variables, types, etc. It's evidence for my point, not yours. I don't know what "flaw" you are talking about, and from that point on your criticisms are not specific enough for me to know what the hell you are talking about. Yet more sloth on your part. Shape up or go away. Whenever you see something in a model you don't personally like, you label it as a "flaw", being the drama queen you are. Nothing is objectively broken. And how does one verify and measure "given" in "each variable is given...". Do you have a Give-O-Meter? Are you going to tell me "given" "has a special meaning in computer science, and if you read my stack of canon books, you'd JUST KNOW what that special meaning is".
** {Of course there are multiple ways to handle variables, nobody said otherwise (talk about RedHerring''''''s). However, it did give the usual (or canonical) definition of variable. That supports my side and not yours. Now, can you find any evidence to the contrary? No, I don't label things I don't like flaws. I do, however, label errors, such as using the incorrect definitions, flaws. And no, you wouldn't "JUST KNOW" what that special meaning is, you would be told what that special meaning is. Many of them will give you examples and exercises designed to help you understand that special meaning.}
** Stop the patronizing crap. I know how typical languages '''behave''' (IoProfile) already. I'm looking for a definition and/or model of dynamic types that is clear and non-arbitrary. (My model is arbitrary in that I don't claim it the only possible model nor a "canon".) I don't see how that definition of "variable" contradicts my model. Besides I not even out to define "variable". The focus should be on types.
*** {I didn't supply that definition to contradict your definition of variable. I supplied it as evidence for my claim about what the canonical definition was.}
*** PageAnchor Find-Good-Enough
*** I don't see how that follows from that example. Docs typically do not describe (or at least heavily rely on descriptions of) internal formats in terms of nesting, pointer relationships, internal data structures, etc. As long as the interpreter can ''somehow'' find the associated parts when needed (such as type indicator(s) and value representation(s)), the documentation doesn't have to directly focus on such. The downside is that IF somebody wants to construct a specific (computer runnable) model or implementation, the '''docs don't narrow choices''' among multiple ways to implement the same thing.  Anybody trying to glean specific implementations off of English words like "has" and "is" and "references" are in for a long night unless they accept that their interpretation is largely arbitrary. -t
*** ''"As long as the interpreter can somehow find the associated parts when needed" is a good interpretation of the abstract definition.  It '''should''' be broad enough to encompass any possible implementation, without dictating an implementation approach.  It means any technical approach that (for example) associates a value representation with a type is sufficient to be a "value".  The association must exist, but how, where, and what is used to make it exist is up to the language designer and implementer.''
*** Exactly. There is no canon model/implementation. At best we can get occurrence measurements: 30% use technique X, 20% use technique Y, etc.
*** ''There is no canon about how you implement a language.  There is certainly a de facto canon about how value, type, variable (particularly in terms of DynamicallyTyped vs StaticallyTyped languages), constant, and literal are defined -- particularly around (but not limited to) popular imperative programming languages.  Implement any language interpreter/compiler how you like, but if you implement values, types, variables, constants and literals such that your language has conventional FORTRAN, COBOL, Lisp and/or Algol-derived semantics -- whether StaticallyTyped or DynamicallyTyped -- ComputerScience has a conventional and encompassing description of those semantics.  I've summarised it at TypeSystemCategoriesInImperativeLanguages.''
*** Bullshet, the tag model can model those languages just fine. "De facto canon", if that ain't an oxymoron, I don't know what is. Is that like "accidental intent"? Too much horse stuff in paragraph. And many of those languages were around before OOP was common. Thus, the parametric polymorphism of TypeSystemCategoriesInImperativeLanguages is after their time. What was the "de facto canon" (cough) before OOP was common?
*** ''I'm sure the "tag model" can model those languages just fine, though it employs unfamiliar terminology and confusingly adds a type attribute to variables in DynamicallyTyped languages which makes them look like StaticallyTyped variables, and no one has ever heard of it except you, me, and the other two or three people who have bothered to read the relevant pages.  "De facto canon" simply means it's the conventional explanation that has arisen organically over the last forty-odd years; there isn't a single definitive reference -- like there is for, say, the RelationalModel: Codd's "A Relational Model for Large Shared Databanks" -- or a specified informal standard like an RFC.  As for the parametric polymorphism of DynamicallyTyped languages on TypeSystemCategoriesInImperativeLanguages, it describes semantics; how languages implement it is irrelevant.''
*** I will agree that the parametric polymorphism approach is ''currently'' the favored approach (or at least the "in-style" approach) to document much of dynamic typing (more on this later). However, the structure/relationships of "variables", values/representation, and type indicators does NOT reflect anything common. You are merely documenting your personal preference and/or implementer preference. It doesn't fit an magic fuzzy "semantics" canon. '''You are hallucinating its existence'''.  And almost all models have internal parts. Complaining about the internal parts of my model is like complaining about the gears in an orrery. Likewise, I found "representation" awkward in your model. It's all about trade-offs: '''real world usage is overloaded''', but a specific model has to commit to certain names, forcing one to choose one specific interpretation/usage over another. Both models take a hit in a different spot to deal with that issue. I explained my naming decisions as carefully and detailed as I can. If you disagree, so be it. (Typically we have different goals and/or working assumptions about typical developer WetWare. My choices are logical based on my stated goals and WetWare assumptions.)
*** ''No, I am not documenting my personal preference.  I am summarising documentation from various ComputerScience textbooks, particularly those by DateAndDarwen, because significant emphasis in TheThirdManifesto is about addressing the rather loose distinctions made by casual sources like the infamous PHP manual.  Your own desire to create a new model to address what you see as fuzziness in colloquial terminology is undoubtedly motivated by observing the same thing.  However, that does not mean ComputerScience, or even SoftwareEngineering, is unclear about the nature of and distinctions between values, variables, types, operators, literals and constants.''
**** Re: "I am summarising..." - That's the problem, the reader can't see the details that go into the summary. And one book does not a canon make. It is possible to do proper textual analysis of multiple sources, but you are too lazy to, and then harass me for not accepting your authoritative summary. '''Either do it right or shut up about canons.''' Put some real details behind your mouth like the "proper" academic you claim to be. 
**** ''See pages 12, 13 and 283 of http://www.dcs.warwick.ac.uk/~hugh/TTM/DTATRM.pdf  Their terminology (and writing style) is slightly nuanced, as reflects its academic audience and subject matter.  Almost any standard 1st year text on ComputerScience will provide equivalent conventional explanations.'' 
**** It describes a theoretical or conceptual model. I have no problem with that per se, but that does not make it a canon, nor says anything about '''runnable  models'''. We can pretend there is only one integer value "12" in the universe in a kind of existential sense (as described by the link), but it's usually not PRACTICAL for a runnable model to reference a single instance of that "12" in order to mirror this existential uniqueness. Your model doesn't do it nor does mine. Even IF one accepts the existential canon that there is one and only one value "12" in the universe, no practical model can mirror that conceptual view. Even YOU chose not to in your model, duplicating "12" if two more variables share the "same value" of 12. I'm not going to complicate my model to mirror an existential view either. You took the practical route for "12", but why won't you accept the same "reality/practicality adjustment" for the structuring of a "variable"? It appears to be hypocrisy at face value. -t
**** Continued at MappingTheoryToRunnableModels...

*** Actually, the model discussions should split the "variable structure" issue from the operator decision/behavior aspect (polymorphism). They are generally orthogonal and one could swap that part. My model's operation/decision model is more general, as discussed in SignaturesAndSoftPolymorphism. I realize there is a trade-off in being more general, and we'll never agree about which trade-off is "right". Let both exist and '''let the reader apply''' them as needed. Contemplating the trade-offs of each is a good mental exercise for those studying types regardless of whether it's "in style" or not. Knowing why the industry uses X instead of Y requires studying Y. That's '''better than taking X on faith'''. (Modeling "what is" and modeling "should" are two different things. "Soft polymorphism" can handle a wider variety of crudy and junky languages that one may encounter.) -t
**** ''I have no idea what that means.''
*** ''So-called "soft polymorphism" -- if I understand what you mean by that -- appears to be addressed in TypeSystemCategoriesInImperativeLanguages, under "Some languages do not distinguish operand types outside of operators ..."''
*** As worded, I find it vague, akin to FractalVagueness and circular definitions. Nor does it actually illustrate it happening with sample code.
*** ''You seem to find much to be vague.  Why is it only you?  As for an example, see C''''''oldFusion.''
*** Like I have said multiple times, Mr. Forgetty, most don't dwell on it heavily, they '''spot fix problems''' where encountered. Similarly, I got by the same way for many years using fuzzy notions that were GoodEnough. Curiosity eventually led me to explore predictive models. The fact that the Php manual and your "Boolean variables" source seemed to have "missed it up" (from your perspective) is some evidence that there's a general communication problem in dynamic land.
*** ''Typographical errors are legion in documentation, so I wouldn't put any significance on the "Boolean variables" one.  The PHP manual is more of an issue, though it's perhaps uniquely bad.  Such confusion about BasicLanguageConcepts does not appear in any other popular programming language reference.  If there's a need for anything, it's perhaps better -- or at least more pervasive -- documentation of the conventional model.  We don't need a new model, with its own unique terminology and quirks, in order to improve existing documentation.  We just need to improve existing documentation.''
*** I'm not sure I agree it's "conventional". There is no documented canon or anything even close to a documented canon.  Your model also has terminology issues in my opinion. There's no free lunch, only the balancing of trade-offs. We have several pages arguing the merits of each model and I won't repeat those debate points here. And I'm not sure existing documentation can be improved withOUT introducing arbitrary model choices; the situation appears to be inherently suck with VagueOrArbitrary.
*** ''Why do you think there's "no documented canon or anything even close to a documented canon"?''

** ''How could the focus be on types?  Your IoProfile doesn't mention types, and your "tag model" evades types.  Furthermore, how does your IoProfile allow you to "know how typical languages behave", given that it appears to only be a technique for verifying that two language implementations might be the same language based on I/O?  I thought behaviour (i.e., semantics) didn't enter into it.  Finally, the definition of variable mentioned above contradicts your model in that it has no explicit 'type' attribute in DynamicallyTyped languages.  Your variable does.''
** How does it "evade types"? IoProfile can be used on a StepwiseRefinement basis. We can test a whole program, an expression, or a single operator. I never limited it to entire programs (although for testing purposes we typically need to package our code as "programs"). And you seem to be conflating behavior and semantics. I/O profile is a measure of behavior. Semantics is related to human thought patterns, and is harder to objectively analyze. And I don't know how you are measuring has-ness per "variable" complaint. It appears to be model favoritism rather than an objective or "official" trait of variables.
** ''Your "tag model" evades types by (apparently) renaming what would otherwise be known as a "type reference" to "tag", not defining "tag", and not mentioning types.  Semantics are not related to human thought patterns.  Semantics are the mapping of symbols to meanings, where "meanings" in terms of programming languages are the interaction of elements or "parts" of the language.  In other words, programming language semantics maps syntax to language behaviour.  I have no idea what you mean by "has-ness", but your description of a variable in your model has an explicit "type" attribute which does not appear in the reference -- http://en.wikiversity.org/wiki/Introduction_to_Programming/Variables -- mentioned above.  Thus, as noted above, it contradicts your model.''
** "Tag" is short for "type tag". Whether it "is" a "type-reference" or not is a vocab issue, not really a model issue. "Type reference" is not that common in colloquial land such that using/applying it or not has small if any ''practical'' consequences.
** ''Even the use of "tag" instead of "type tag" seems to be an attempt to avoid mention of types.  It's true that "type reference" is not that common, because it's usually shorted to "type".  Why not say "type"?''
*** I wish to label a specific model part in a way that reduces chance of confusion with general overloaded colloquial terms. I'm pretty sure we've had this discussion before. There is no conspiracy to avoid saying "type". It's called a "type tag" up front and shortened to "tag" in areas of frequent use to make the text more concise. It's a common an accepted practice. You are quibbling over small things here.
*** ''Perhaps, but this did start from your claim that "the focus should be on types", but you appear to avoid any mention of types.''
*** The formal structures call it "type_tag". I reject your complaint.
*** ''What formal structures?''
*** "type_tag" occurs 6 times in TopsTagModelTwo. How many occurrences will make you stop bitching? 12? 48? 39024?
*** ''Zero occurrences would make me stop bitching.  Call it what it is: "type" or "type reference".''
** And there are MULTIPLE ways to "maps syntax to language behaviour".
** ''Sure.  So?  Trivially, 'a = b + 3' can mean "invoke the '+' operator on the value denoted by the literal '3' and the value in variable b and assign the resulting value to variable a", or it can mean "rotate polygon 'a' 3 degrees about the axis specified by 'b'" or it can mean an infinite number of other things.  What it means is up to the language designer.  However, if the language is a popular imperative programming language, it's the first meaning every time.''
*** I'm not talking about "wrong" behavior. That should be obvious. Let me restate it. There are multiple ways to map syntax to EXISTING popular imperative programming language behavior, as our two different models demonstrate.
*** ''Who said anything about "wrong" behaviour?  It's true that there are multiple ways to map syntax to existing popular imperative programming language behaviour, but one way is recognised, and the other way is yours, which relies on your own unconventional terminology, definitions, and structures.''
*** "Recognized" by what? Are you hallucinating canons again? Tell the white rabbit to remove it.
*** ''Recognised by ComputerScience, along with at least several other participants on these pages.''
*** I'm not taking your word for it. I'd like to see a more formal survey. And one paid interpreter implementer didn't do it your way. There may be an implementation proportion difference, count-wise, but a Wankle engine is no less a "gasoline engine" than a cylinder engine just because it's used less often. My model is NOT intended to prepare users for an academic career.
*** ''Your "paid interpreter implementer" (DavidClarkd?) implemented StaticallyTyped variables.  Presumably -- his descriptions were such a muddle of theory, implementation, and AdHominem that it was hard to tell, and his personal Web site seems to be gone now so we might never know.  As for your "survey", please, look in some textbooks.  This is all elementary stuff.''
*** The books as is are vague. We've been over this already multiple times. The result is usually similar to above near PageAnchor human_languages_26 where I dissect the English words of ''your own'' text.
*** ''I think it more accurate to state that '''you''' find the books to be vague.  If they really were vague, how would anyone ever manage to write a working compiler or interpreter?''
*** ''Where did you "dissect the English words of [my own] text"?  I see some quibbling on your part, and then in human_languages_26 I point out that formal languages make meanings concisely precise when English becomes too verbose.  That doesn't mean that the English meanings are vague, only that they lack the concise logical rigour of formal language.  You can easily write mechanically-provable logical proofs for statements in a formal language, but it would be painfully tedious for English, despite everyone knowing '''exactly''' what the English language means.''
*** You only CLAIM they "know exactly". My experience in the field says otherwise. Fuzzy notions are good enough to get work done, as I have explained multiple times.
*** ''In this case, I meant in the abstract. For example, it is painful to construct rigorous logical proofs in plain English -- e.g., to prove that there exist two irrational numbers x, y such that x^y is rational -- but straightforward in a formal language (or notation), even though everyone knows exactly what "two", "irrational", "rational", "number", '^' and 'x' & 'y' mean.'' 
*** I agree: all known texts written in "plain English" (your words) are vague or ambiguous. No argument there. Special notations and/or terms can be created to model a specific implementation or viewpoint of "types", but it's a PrivateLanguage.
*** ''I didn't say plain English is vague or ambiguous.  It can be perfectly precise and unambiguous, but only at the expense of conciseness.  Formal languages can be precise, unambiguous, and concise, and formal languages like Z are anything but a PrivateLanguage.''

** By "has-ness", I meant how does one objectively verify "it has no explicit 'type' attribute". And what EXACTLY does "explicit" mean in this context? You are defining fuzz with more fuzz (FractalVagueness).
** ''Here, I'm not defining anything, so I'm not sure how that can be the case.  You know what "explicit" means -- we've gone over it before -- so there's no point in quibbling over it.  Again, there is no language semantic in a DynamicallyTyped popular imperative programming language that makes reference to the type of a variable independent of its value.''
*** You only claim that (repeatedly in an annoying way); you haven't shown it to be the case except by interjecting your PERSONAL preference or personally favored interpretation of English per vague descriptions. As far as written manuals, we've seen Php's setType imply such. Nor do others explicitly preclude it. And if you defined your use of "explicit", I forgot it.
*** ''We've already established that PHP's settype() is not setting a variable type, it's changing a variable's value.  See Example 1 in the documentation.''
*** Sorry, I see nothing new revealed.
*** ''See how the values changed in Example 1, and not just a type?  "5bar" became 5, and true became "1".  Those are different values, not just different types for the same value.''
*** The value changing doesn't preclude the type from also changing. It's not mutually exclusive. Perhaps they should have said, "Changes the type of the variable, and sometimes the value also." But the intro description is merely a summary, not a legal contract. That's why they have explanations and examples: to flesh out specifics.
*** ''Perhaps they should have said, "changes the type of the variable, and sometimes the value also", except they wouldn't say that because that's not what it does.  It changes the value, every single time.  There is no "variable type" to change independently of the value, because "value" immutably binds type and representation.  It wouldn't make sense, either.  Under what conditions would it change the type but not the value, and under what conditions would it change the value and the type?  How would it decide?''
*** Those are implementation details, and there are probably multiple ways to match the same language behavior (IoProfile). And the "immutability" thing is your personal model preference, not an external reality nor documented canon.
*** ''No, "implementation details" are precisely what it is '''not'''.  It's a description of the semantics.  How it's implemented doesn't matter.''
*** No, it's not.
*** ''What is your basis for that?''
*** My basis is that you have no proof of that claim about semantics. A description may be influenced by semantics, but to say it "is" semantics will require real evidence, not personal conjecture.
*** ''Given a language L, where do the semantics for language L come from?''

** And your link has a titled section called "Variable Types". Did you miss it? I see zero contractions. 
** ''Read the section.  It's specifically about StaticallyTyped variables, for which there is no argument (I hope!) over the fact that StaticallyTyped variables have an explicit 'type' attribute used to determine whether or not the value of a proposed assignment is compatible with the type of the variable.  That semantic '''does''' make reference to the type of a variable independent of its value (obviously, because it's not assigned a value yet), so an explicit 'type' attribute is needed in StaticallyTyped languages.  No such need exists in DynamicallyTyped languages.  Indeed, what makes a language DynamicallyTyped is the fact that any value can be assigned to a variable.''
** As I read it, the context is NOT clearly static for that entire section. If it were ONLY for static, then it should have said up front on the first line or two, not half way through.
** ''The preceding text is purely set-up for the subsequent text.  The set-up is: "Most languages have a variety of primitive types such as integers, floating point numbers, single characters and Boolean variables. [It appears the last word of this sentence should be "types", not variables, otherwise they'd be making the nonsensical statement that variables are primitive types.] Many languages also support a variety of aggregate types (eg. arrays). The exact size and format of available types may vary based upon operating system, hardware architecture, programming language and/or the specific compiler used."  No mention of variables there, aside from what is obviously a mistake.  Then it launches into discussion of '''static typing''', which I've put in bold because that's what the reference does.''
** You keep calling any text found in external sources "errors" if they don't fit your pet notions. You are mistaking your personal head models for universal truths. Knock it off!
** ''It is an error.  Do you really think they meant to suggest that variables are primitive types?  That doesn't make sense.''
** PageAnchor biasEvidence9489
** That's YOUR interpretation of the words. You are debugging YOUR mind's interpretation of it. "Boolean variable" could ALSO be interpreted as "Variable having a Boolean type". More evidence you are biased because you cannot consider multiple possible interpretations. 
** ''So you think they wrote "Most languages have a variety of primitive types such as integers, floating point numbers, single characters and Boolean variables" because they meant "Most languages have a variety of primitive types such as integers, floating point numbers, single characters and variables having a Boolean type"?  That doesn't make sense; single characters, floating point numbers and integers aren't variables.  What '''does''' make sense is "Most languages have a variety of primitive types such as integers, floating point numbers, single characters and Boolean types."''
**  It's "normal" English to talk about "numbers", "strings", "dates" etc. as stand-alone nouns. However, we don't normally say "Booleans" in the same way (although it's fairly common in face-to-face colloquial speak). The author thus had to put a noun in there to make it proper English. Why they rejected "type" over "variable", I don't know. We can only speculate. I would note the choice is consistent with the section title. If the author F'd up, they F'd up twice it appears in the same way. -t
** ''The author probably saw the word "variable" in the title above -- where it's entirely appropriate -- and keyed it automatically whilst thinking "type".  It's easy to do.  I do it.  I'm sure you do, too.''

* Further, the boundary between type checking and validation is fuzzy.
** ''That you find my explanation difficult to understand is telling.  It uses terminology familiar to any first year ComputerScience student.  Have you ever taken a course in computer architecture?''
** It's familiar in a rough notion-y sense, not in a clear-cut model. We've been over this already many times repeatedly multiple times redundantly repeatedly.
** ''What part(s) do you find not clear?''
** When I ask you to define A, you define it in terms of B and C. When I ask you to define B, you define it in terms of D and E; when I ask you to define D, you define it in terms of F and G, and so forth. It's never ending. I'm using StepwiseRefinement such that there is always a final and last step.
** ''Really?  Where have I done that?''
** Everywhere. The only variation is perhaps, "D is defined by the language maker, and they can make it what they want. See their wonderful manual to answer that.....oops, their manual sucks. Too bad."
** ''In the absence of specific evidence it cannot be confirmed, and therefore must be considered your opinion rather than fact.''
** It's clear by default? What Grand Logic rule says that?
** ''What rule says it's unclear by default?  If you're going to allege a flaw, it seems reasonable to point out the flaw in sufficient detail to be able to locate it.  You have not done so.  If you can't do it, then it's reasonable to assume the flaw doesn't exist and you're only alleging a flaw exists for rhetorical effect.''
** Fine, it's fuzzy TO ME. I have a hard to time figuring it out beyond a vague notion. And my anecdotal experience talking to other developers is that they too mostly only work with fuzzy notions of "types" in dynamic languages. That's why I developed the tag model: to be able to model specific behavior of languages in a way that makes sense to most developers. I'm at a loss to explain why it's fuzzy in a way that satisfies you. Your explanations just seem to follow the "letter pattern" above. Your explanations seem to be tied to alien models in YOUR head, not something that is concrete to my world or way thinking.
** ''I wonder if the "alien models" in my head are nothing more than a foundation knowledge of computer architecture, including typical data representations.  That's what I was taught when I did my undergrad degree in ComputerScience, and it's taught in the university where I work, and I've assumed it's a component of every ComputerScience or SoftwareEngineering degree.  It certainly is for those I know about.  But maybe some degree courses skip it entirely, which means students learn ComputerScience or SoftwareEngineering with very different conceptual foundations from those that I assume.  I can imagine that graduates of such courses might see my approaches as "alien models".''
** {The local high schools here are also teaching this "alien model" and the students don't appear to be having any difficulties with it.}
** I believe that statement to be flat wrong. I don't know where you two guys work, but your notion of what typical developers know and do seems just plain devoid of reality. Yes, they teach a rough general "notion" of types, but it's the devilish details that matter here. And Mr. Italics below '''admitted that the details were language-specific''' such that general concepts are not sufficient to explain/model specific languages. Thus, you two appear to be conflicting.
*** {Whatever it may appear to be in your eyes, we've not contradicted each other. The fact that there is more than one thing that meets the definition of a group (in the algebraic sense), does not make "group" ill-defined or fuzzy. Likewise, the fact that there is more than one type system in existence doesn't mean that "types" are a rough general notion.}
** ''The details may be language-specific, but the general principles are universal among popular imperative programming languages.  The descriptions at the top of TypeSystemCategoriesInImperativeLanguages are accurate, regardless how individual languages implement them.  As for the statement being wrong, my experience is the same -- even pre-highschool kids pick up the "alien model" principles with no difficulty.''
** I've seen good documentation, and TypeSystemCategoriesInImperativeLanguages certainly is NOT it.
** ''That may be true; I'm a programmer and university lecturer. I make no claims to being a technical writer.  But if it's poor, the problem is merely the writing, not the model.  Regardless how it is written, the descriptions are accurate and can be used to predict all type-related behaviour in popular imperative programming languages, and it is precisely this "alien model" that kids are successfully learning.''
** How are you measuring this alleged "success"?
** ''By the number of students who come into 1st year university being not only able to program, but program well, often in Javascript, Java, PHP or even C++, and some since they were four or five.''
** I don't meet many such prodigies. Perhaps your university gets the elite applicants whereas I encounter Average Joe programmers. Besides, one can program in those languages well if they know them well, but that's not necessarily the same as having a '''conscience mental model''' of how the TypeSystem works (or doesn't work). Experience will often give one "horse sense" in that they "feel" a certain programming pattern should or shouldn't be used for a given spot based on repeated training. But this is more like traditional neural-net "training" (essentially statistical frequency matching) and not necessarily a conscience plan or model. 
** ''For unrelated reasons, I reviewed our entrance stats earlier today and determined that we have over 38% "AAB" students in 1st year, which in edu-speak means "the bright kids".  Perhaps that accounts for it, but I haven't noticed any difficulty with the other students picking up programming and TypeSystem fundamentals, except for those who have trouble with programming in general.  For those, even the most trivial programming stumps them.  In most cases, we never get to types before they decide to do something else.  Everything after you wrote "Besides ..." I couldn't follow at all.  Sorry.  I don't know what a "conscience mental model" is.''
** The inconsistency between Php's is_bool and is_numeric functions (and the fact that few really even care) shows that even language builders can be lackadaisical about such issues. (The first only checks the "type tag" while the second only appears to parse the "representation" of the value and ignores the tag).
** ''By "tag", do you mean a type reference?  Yes, that's what those functions do.''
** You and I define "do" differently, as debated probably at least 3 times already.
** ''Really?  Are you now disagreeing with my agreement with you? *boggle*''
** Just please avoid the word "do".
** ''What's wrong with "do"?  Code "does" stuff, doesn't it?''
** It takes input and produces output. If you say "functions do X", you need to show that in terms of I/O. Your "type reference" can be part of a PARTICULAR model of I/O, but that doesn't make it a universal truth, only a part in a given model, which may be one of many different models that mirror/predict I/O. If you can logically prove that '''"ALL accurate models must have part X"''', please do. Oops, I said "do". My bad.
** ''If you define functions in terms of input and output and not what they do, then if two functions have the same signatures but one implements bubblesort and the other implements quicksort, are they the same?''
** In terms of output, yes! Machine speed is not an issue when a developer is trying to predict/model type-related behavior. The key here is "in terms of". If we don't need to care about speed for a given goal, then we can perhaps simplify the model to achieve such by sacrificing speed. I stated my target goals and fit them. Speed was not a top goal. You agreed to not include caching etc. in your model for similar reasons, if I am not mistaking. (I don't know if those two sorts produce the same result for ties.) 
** ''That's reasonable -- I wanted to be clear on what you intended.  In essence, you're saying you're solely interested -- for modelling purposes -- in the type-compatibility of parameters, values and variables, but you use the term "anonymous variable" for values and the term "variable" for parameters and variables, and use the term "tag" for "type reference".  Your model is the conventional one, but with unconventional terminology.''
** I don't recall seeing the term "type reference" much in language manuals. Whether it's the "proper" term or not is mostly moot if most of the audience of the model hasn't had a lot of exposure to it. 
** ''The usual term in language manuals, in the context of values and variables, is simply "type".''
** Which is overloaded with "parse-like" typing, which is NOT the same as a "tag" based typing, which you say looks the same as "type reference" which is allegedly the same as "type" in typical docs which seems like a contradiction.
** ''What is it that you're saying is contradictory to what?''

	tag != parse-like-typing
	tag == type-reference
	type-reference == type
	Thus: tag == type
	type == parse-like-typing (in colloquial-speak, or "contains")
	Thus:
	tag == parse-like-typing  (contradicts 1st)
.
** ''"Type" is short for "type reference" in the context of values and variables.  That does not mean a type reference is a type.  It means a value or variable with a type reference has, or is associated with, a type.''
*** Where? What "thing" has this trait? Can parsing be used to determine "is associated with"? How long does this associate-ness last? That sentence is very fuzzy to me. My head cannot do anything concrete with it.
*** ''I thought that might be the case, so I already explained it in the bullet point immediately below this one.  See "At compile-time in Category D1 languages..."''
** ''At compile-time in Category D1 languages, literals encoded in the source code are parsed by the interpreter to determine their type, and a "tag" -- i.e., a type reference -- identifying the type is permanently associated with the value the literal represented.  At run-time, literals encoded in string values are parsed by functions like cfArgument or is_Numeric() to determine their type.  There is no contradiction here.  The above should be:''
	Compile time:
	type is determined by parsing source code during LexicalAnalysis
	type-reference refers to type
	type-reference is associated with value
	Run time:
	type is determined by parsing values using cfArgument, isNumeric(), etc.
.

** is_numeric() does not look at (use), change, or create a tag (or at least is consistent with a model with such rules).
** ''I didn't say it did.'' 
** By the way, we don't need to model a "compile" step to mirror most dynamic languages. There is no reason to complicate a model by talking about or modeling a compile step.
** ''That's fine.  How about this:''
	Literals and their types are identified by parsing source code.  Each literal is turned into a value with a reference to its type.
	Values of other types may be identified by parsing strings using cfArgument, isNumeric(), etc.
.	
** Why use the word "other"?
** ''Maybe it doesn't add anything.  How about:''
	The interpreter identifies the type of each literal by parsing the source code.  Each literal is turned into a value with a reference to its type.
	If a string contains a literal, its type may be verified by parsing the string using cfArgument (ColdFusion), is_numeric() (PHP), etc.
.
** ''Since it isn't a distinguishing factor, we can remove mention of parsing to leave:''
	For each literal in the source code, the interpreter determines its type and internally converts it to a value with a reference to its type.
	If a string contains a literal, the literal's type may be verified using cfArgument (ColdFusion), is_numeric() (PHP), etc.
.
** Why have "If a string contains..."? I'm not even sure what that refers to. You need to provide explicit names (ID's) for things. Unique identifiers are a good thing if you want clear explanations. Is_numeric() returns a result regardless of how its contents were assigned. Thus, there is no need for "if", although I'm not quite sure what your actual intent was. -t
** ''Given a string "123", which contains the literal 123 that we suspect is numeric, we pass it to is_numeric() to see if it is numeric.  In other words, if it contains a literal -- which it does -- the literal's type may be verified using is_numeric by invoking is_numeric("123").  I could probably simplify it further.  How about:''
	For each literal in the source code, the interpreter determines its type and internally converts it to a value with a reference to its type.
	The type of a literal which is encoded in a string can be verified using cfArgument (ColdFusion), is_numeric() (PHP), etc.
.
** It looks to me like you are jumping back a step. You talk about an intermediate object, and then refer to the original after that ("literal"). Once you talk about the intermediate object, in my opinion, it's best to stick with that as your working verbal reference point unless there is a compelling reason to jump back. And IF you do jump back, make sure it's clear which object is being discussed.
** ''How about:''
	For each literal in the source code, the interpreter determines its type and internally converts it to a value with a reference to its type.
	Strings can be checked to see if they represent literals of specified types using cfArgument (ColdFusion), is_numeric() (PHP), etc.
.
** ''I'm not clear what you mean by, "You need to provide explicit names (ID's) for things."  There are no individual items mentioned, so I'm not sure what would be given IDs.''
** I don't know which "thing" is being referenced. The relationship of the nouns in the 2nd sentence to the first sentence is not explicit. Which "string"? Which "literal"? I suggested removing the "for each" approach and focus on one at a time to simplify references and context. For one, interpreters only have to process literals that the "program pointer" actually encounters. I realize a pre-parse is often done, but is not a necessary step for interpreters.
** ''I see.  How about:''
	The interpreter converts literals in the source code to values, where each value has a reference to its type.
	Strings can be checked to see if they represent literals of specified types using cfArgument (ColdFusion), is_numeric() (PHP), etc.
.
** It's not clear what a "string" is in your model. Is it a "value" by itself? A value with a type reference? A value with a type reference of "String"? And "represent" is also a bit vague. Humans can often guess intent of content/literal authors, but we need something more specific in this case.
** ''Ok.  Try this:''
	The interpreter converts literals in the source code to values, where each value has a reference to its type.
	Values with a reference to the "string" type -- i.e., values of type string aka "strings" -- can be checked to 
	see if they contain a sequence of characters that represents a literal of a specified type, 
	using functions like cfArgument (ColdFusion), is_numeric() (PHP), etc.
.
** It's an improvement. But your use of "of" in "of a specified type" is bothersome. It's as if you are mentioning a function called something like "isOfType()", but not defining what this of-ness function does (how it affects output or measurable activity). In colloquial speak, it's normal to say Php's is_numeric() function will "tell you if the operand is ''of'' a numeric type". But it's also acceptable to say "getType() will tell you if the operand is ''of'' a numeric type". So which pattern does "of" reflect, since each (colloquially legitimate) interpretation path produces a potentially different result: a given variable "has" or "references" TWO types at the same time. But your use of "a" in "has a reference to type" suggests there only be one type. The description does not answer this potential reader puzzle. Also, is_numeric works on non-strings (tag=int) such that the description seems incomplete or at least misleading, implying they only "work on" strings (tag=string). Otherwise, why mention strings? The reader may likely ask why strings are being mentioned at that spot. is_numeric's results do NOT by themselves confirm "contain a sequence of characters that represents a literal of a specified type" since we don't know if an Integer "contains a sequence of characters" based on what's given. Thus, (without constraints) it's a weak detector of the condition you describe such that perhaps it should not be mentioned, because otherwise it may be legitimately mistaken for the single and only test. Or perhaps word it as "function X can ''help'' determine if" rather than "function X determines if" (paraphrased). But then it begs the question of how full determination is done, which should then be given or linked to in good docs rather than leave the reader hanging with just one of the multiple "helper" functions necessary. In a medical book, you shouldn't say "a stethoscope determines if you have a bad heart" because it's not the end-all-be-all of heart tests. You could say "a stethoscope can ''help'' determine if you have a bad heart", but in that case fuller tests should be described or referenced. Otherwise, move or change around the whole thing.
** Further, it doesn't exclude the interpreter from checking in the "type reference" for "sequence of characters". As written, that's a valid interpretation, but it's not reflective of how Php behaves. That's why I try to explicitly label all parts and containers. Then I can say "looks inside of component X". And if component Y has been stated to be "in component X", then it's fair to assume Y is also looked at. Your description ("has") is nebulous about such relationships. If you say "value A has a reference to B" and you say "foo looks at/in A", '''it's not clear whether that "looks at" also includes B'''. "Has reference" does not hard-force one interpretation over the other. '''Both interpretations are valid in common English'''. That's an illustration of why English sucks for tech docs. I'd lean toward excluding B as written, but there is no solid rule that "at" or "in" excludes "reference following" in colloquial English. And the "reference" ITSELF may also have characters that apply even IF we exclude what is actually being pointed to. Thus, it could be looking at the URL even if it excludes the web page (HTML) at that URL. I think I know what you ''meant'' after all our haggling, but you cannot assume a new reader will also.
** PageAnchor human_languages_26
** ''There's an inevitable point where the inherent ambiguity of human language makes further precision possible only by being painfully verbose, and a choice has to be made between a short, simple, but potentially somewhat ambiguous description and a long, complex, precise description.  The need for the latter is why academic writing is often described as dense and difficult.  It's an inevitable result of being precise and rigorous.  One reason we use notations is because they significantly reduce such ambiguity without being verbose, at the expense of (initially, at least) not being particularly reader-friendly.''

*** Yes, English is inherently ambiguous. That we can agree on. The issue is what to do about it. If written well, it could be ''less'' ambiguous than your English-centric attempt (or at least I am not particular fond of your writing style, but different WetWare may see something else), and that may go for my written attempts also. We are probably not the best technical writers in the world and probably cannot rely heavily on English. Now, my solution is to use imperative computer algorithms (code or pseudo-code) and data-structure-like XML to give a predictive model of type-related behavior. Developers see these every week and thus they are likely to be quite familiar. Your set-oriented attempt below is perhaps another approach, but a good many developers are not going to absorb such quickly. This, we are proposing two different approaches toward a formal notation. I believe my approach is a better fit to the audience's WetWare (as shaped by experience and filtered by the hiring process). The idea is to leverage what they already know '''well'''. But there's no harm in having two models so one can choose the better fit for themselves. Viva Variety. -t

*** ''I suspect if the audience can't follow the relatively simple semi-formal description below, XML will also probably be lost on the vast majority of them.  One type of "code" is pretty much like another, and as they are weak programmers who are already having difficulty with code, I don't know if more code is the solution.  I sometimes wonder -- when in a grumpy and pessimistic mood -- if the best thing we could do to help poor programmers is to not attempt more explanations, but encourage them to take up another line of work.''
*** A set-centric approach could perhaps be done well, but below is not it. I've seen good documentation before on other topics and so know that such is possible with the right writer. You are not it (at least not for my WetWare.)
*** ''Please point out set-centric (or other) approaches that you feel have been done well on other topics, and I'll try adopting their style.  I'm not attached to one style or another, but as my English descriptions weren't working, I thought a semi-formal approach might work better.  If not, I'm happy to try something else.''
*** Anyhow, why are you comparing XML to the below?
*** ''I'm comparing "code" to "code".''
*** Apples and oranges. Most production code is sequential steps that fill up data structures and empty data structures (or equiv.). Below is not sequential.
*** ''You mean most production code is imperative?  Yes it is, but most imperative code performs computation rather than providing definitions and descriptions.  I've provided definitions and descriptions, just like the English above but replacing some English words with notations and adding some definitions to avoid ambiguity.  As such, it's a static model.  It has no time or order dependencies other than those inherently imposed by references (e.g., T refers to S, so S must be defined before T) so it's declarative rather than imperative.''
*** Sequential is what they know, and that's what my model does.
*** ''So you've said, but TopsTagModelTwo appears to be incomplete, and related pages appear to have no (well, one line of) imperative code.  If I'm missing something, please point me to it.'' 
*** Why are you trying to force your pet mental models on others and punish them if they don't like it? That's selfish. If they can get work done using mental model A, why force mental model B on them? I don't see the economic logic in that.
*** ''I have no objection to there being a plethora of explanations and models.  I have an objection to any explanation or model that relies on undefined new terminology as aliases for existing terminology; that appears to be incomplete; or that outright contradicts standard terminology without compelling justification, like calling values "anonymous variables" when they're not variable and are clearly values.  I object to such explanations or models because they will increase confusion rather than reducing it, which will only make our jobs as developers and educators more difficult.''
*** I still stand by the trade-off choices I made and gave what I feel are good reasons and won't repeat all that here. "Value" is vague, at least outside of the interpreter maker circle. You have very different beliefs about what ''common'' programmers know and how they think and read documentation, and thus you make different choices and recommendations based on that. My model design decisions are consistent with my assumptions about programmer WetWare and listed goals. Neither of us has more than experience to model such WetWare and thus '''we are stuck''' at a anecdote or TopsLaw impasse. If you expect more than this, please state why. You also seem to have an urge to punish common programmers for allegedly not thinking properly, and this I feel is making you biased against a model that does not follow academic tradition.  In the model/kit, I just focus on helping them with a specific issue rather than try to reshape society or IT culture in general. You remind me of a snowboard instructor who was obsessed with "proper technique" such that it delayed people from having fun in the here and now. (Many of them would not likely be around for follow-up lessons.) Maybe that ''was'' you.
*** ''If "value" is vague amongst some group of developers, then that group is lazy.  I suspect they'll find "anonymous variable" just as vague too, because the problem is laziness, not because some apparent vagueness in "value" can be fixed by renaming it to "anonymous variable".  There are ample opportunities to gain greater understanding of "value", "type", "variable", and any other fundamental concept in programming.  If they reject opportunities to learn, or are too apathetic to make an effort to learn, then you're right -- I am biased against them.  I have nothing but support, encouragement and time for programmers who seek greater knowledge and understanding in order to improve their craft.  I have no patience (or, as one of my colleagues likes to say, "Fucks given equals zero!") for "programmers" (and I use the term loosely) who have no interest in improvement.  Of course, that means they'll probably have no interest in your models, either.''
**** They ''do'' want to improve themselves, they just want more approachable ways to learn instead of the way the old guard wants them to out of nostalgia and stubbornness and job security greed. GraceHopper faced similar attitudes when she first proposed the idea of more English-like programming languages. If it weren't for people like her, your type would still be saying anything other than machine language was for "pussies and mama's boys". '''Be willing to explore new models'''. The old stuff is not a Bible locked in stone. Granted, Grace's early attempts were not very good, but they helped pave the way to the Algol-style we benefit from today. Progress sometimes requires trying new things. I'm trying to do to type documentation what Grace did for programming languages. I may fail, but perhaps spark something for the future the way her early attempts did. Existing writing on types sucks big juicy buffalo dicks.
**** ''Is your vulgarity necessary?  You appear to be conflating a reasonable evolution of programming languages to make them easier to use, with explanations about ComputerScience, SoftwareEngineering, and programming language behaviour.  Better explanations are always good, but "better" does not mean constructing fiction -- like the notion that variables have types in dynamically-typed languages, and that there are no values but instead there are "anonymous variables" -- as a result of attempting to make the explanations simpler.  Similarly, you can probably make a simpler explanation of how internal combustion engines work by claiming that hamsters run on little wheels, but it doesn't benefit the struggling mechanical engineer.''
**** It's NOT "science". You are flat wrong. Anyhow, I'll leave the value battle in ValueExistenceProof. And your engine analogy is faulty because it's the mechanic's job to fix the guts. The programming language user is not required to fix the interpreter. Most "explanations" of how languages work under the hood are UsefulLie'''''s anyhow. You admitted things like caching are left out to simplify explanations.
**** ''What's not "science"?  I didn't mention science.  As for the hamster wheel example, it's admittedly contrived and rather weak.  I'll give you a better one that's real and based on science:  A common explanation for how an aeroplane wing works is that greater curvature at the top of the wing causes air to travel a longer distance above the wing than below the wing, which means it has to move faster above the wing than below the wing, and this causes the wing to be pushed up.  It's a familiar model for how a wing works, and it's almost completely wrong.  If it was true, aeroplanes couldn't fly upside-down and symmetrical (including flat) wing profiles (which are used in some cases) wouldn't work.  In fact, the effect is real, but is typically only worth about 2% of overall lift.  98% of the lift is due to the angle of the wing relative to the direction of travel, i.e., the angle of attack.  Stick your hand out of the window of a moving car and angle it upward into the wind to experience the real effect.  So what is gained by the false explanation?  Absolutely nothing.  I'm sure it could be written so that the wrong explanation is shorter and simpler than the correct explanation, but what would be the point?''
**** Again, I define languages in terms of I/O, NOT how the interpreter is actually coded by the interpreter makers. Are we going to have to revisit that yet again? Interpreters are not physical things anyhow so it's difficult for me to see how it lines up with our issue.
**** ''Defining languages in terms of I/O is fine, but that doesn't justify claiming that variables have types in dynamically-typed languages when even the beginning programmer will be told that variables do not have types in dynamically-typed languages, or not mentioning values but instead there are "anonymous variables".  Even a beginning programmer will be told right from the outset that there are values.''
**** My model has "values"; they are just defined/modeled differently than yours. And please leave the "value fight" to the other topic. And I don't know what you mean by the "variables have types..." statement.
**** ''Where are the values?  I thought you had "anonymous variables".  Your variables have a type reference.  Variables, in dynamically-typed languages, do not have type references.  That's why dynamically-typed languages are sometimes called "value typed" -- variables have no type, which is why they can be assigned any value of any type at any time.  Variables have values, and each value has a type.''
**** Php is a dynamic language, and it has "type references", as witnessed through getType().
**** ''Yes.  How does that answer my question, or address my points?''
**** You said, "Variables, in dynamically-typed languages, do not have type references." The other questions are addressed at the stated "value" topic.
**** ''Of course PHP has type references... ...associated with values.  It doesn't have type references associated with variables.''
**** So you claim.
**** ''It's true.  Just look at the language semantics.  A PHP scalar variable can be defined entirely in terms of "retrieve a value given the variable name" and "store a value given the variable name".  There is no "declare variable's type" or "only allow values of type <x> to be assigned to this variable", either of which are commonly found in StaticallyTyped languages and are indicative of a variable being associated with a type.  Furthermore, there is no "retrieve variable's type" or "store variable's type" operations, which would also be indicative of a variable being associated with a type.  In short, the PHP semantics define a variable as only being associated with a value.  Of course, a value is always associated with a type (i.e., has a type reference), but I presume transitive relationships are not at issue here, because you're arguing that a PHP scalar variable has a (semantically) explicit 'type reference' attribute, aren't you?  It doesn't, because the semantics of PHP don't require it.''
**** "There is no..." Prove It! And "can be defined" is not the same as "must be defined". Multiple models may apply to produce the same externally observable behavior.
**** ''I did prove it, in the paragraph above your response.  If you analyse the semantics of PHP, there are no semantics that make reference to a "variable's type" in PHP.  You can, of course, construct alternative meanings for familiar terms -- like define a "typeless value" that forces an alternative semantics in which types are passed around independent of values.  That would require a notion of a "typed variable" in PHP, but you'd quickly discover that for every semantic operation involving a 'typeless value', there is a corresponding semantic operation involving a 'valueless type'.  Thus, it seems parsimonious to combine the 'typeless value' and 'valueless type' into a single semantic construct: a value (of a type).  Of course, that's exactly what popular imperative programming language semantics -- which again go back to a beginning knowledge of ComputerScience -- do.  As a result, there are no language semantics that make reference to a "variable's type", because in a DynamicallyTyped popular imperative programming language, it is sufficient for values to carry type information.''
**** For one, parsimony is not necessarily the ultimate determination device of vocab. The fact you invent such a rule and elevate it to the level of "proof" makes me wonder about your science education. Second Var=(Type,Rep) is more parsimonious than Var=(Val(Type,Rep)) by most observers.
**** ''Parsimony doesn't determine vocabulary.  No one said it did.  Here, we're talking not about the parsimony of some structure, but the parsimony of the language semantics.  For example, we say a value is assigned to a variable.  We don't say a value and a type are assigned to a variable.''
***** That's just short-hand. If you ask developers if types are "inside" values or not, you'll probably get a wide variety of answers.
***** ''Whilst it may be interesting to survey developers to see what conceptions and misconceptions are typical, their views are irrelevant.  We're talking about language semantics defined by ComputerScience, not casual misunderstandings of them.''
***** You are inventing fake canons out of your arse.
***** ''Why do you think that?  This is basic introductory-textbook material.  Surely you encountered it in college?''
***** Yes, but it was vague. We've been over this already somewhere I'm 99% sure.
***** ''Are you sure you're not letting your personal experience of vagueness drive your perception that it's vague in general?''
***** Search for "Whenever we go over such text, it typically leads to the same kind of situation that led to the discussion just before" below.

**** You are just biased and thus see it wrong in your biased head, due to stubbornness.
**** ''Insults will help support your argument, how?''
**** Third, you've been caught FLAT WRONG: http://php.net/manual/en/function.gettype.php : "string gettype ( mixed $var ); Returns the type of the PHP variable ''var''. (10/13/2014)" (Re: "If you analyse the semantics of PHP, there are no semantics that make reference to a "variable's type" in PHP") EAT CROW, WRONGBOY! Munch it munch munch it! -t
**** [The PHP documentation is notoriously horrendous; in many places, including the page you just linked, it erroneously conflates variables and values. The gettype() function in PHP accepts any kind of expression, not merely simple variables. For example, gettype("some string") and gettype(f()) will both be accepted. In all cases, gettype() receives a value and returns a string describing that value's type. There is no language semantic in PHP that makes reference to a variable's type. -DavidMcLean]
**** ''Exactly.''
**** If you don't like the evidence, you declare it wrong or a mistake.
**** [Given that it's wrong, declaring it so seems an eminently reasonable response. Again, gettype() does not take a variable as its parameter; it's trivially observable that it can accept any expression, including things like gettype(f()), and that it always returns a string describing the type of the value passed to it. PHP's documentation sucks. We all know this. Note that the documentation for the equivalent operators in JavaScript ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof ), Python ( https://docs.python.org/2/library/functions.html#type ), and Ruby ( http://ruby-doc.org/core-2.1.3/Object.html#method-i-class ) does not conflate variables and values in this way. -DavidMcLean]
**** I agree it should say "variable or expression" or just "expression". However, settype says "Set the type of a variable" and is observationally accurate since you cannot set the type of an expression (at least be able to see the effects). "Values" are a UsefulLie '''in the head''' and don't actually correspond to anything objectively observable in Php, such as syntax "objects" or patterns or I/O. You've failed ValueExistenceProof because you have no proof. You claim if one reads enough books on types and languages they'll "just know" that values objectively exist (and contain types). "Just know" is weak, anti-scientific, and shameful. '''You mistake tradition and/or your personal head model for objective truth.''' Straiten up and fly right; you are getting academically sloppy.
**** ''If you read the explanation for settype(), you'll see it's typical PHP misnamed bodgery.  Settype doesn't set the type of a variable, it converts the variable's value from one type to another.  Whilst "values" don't have a syntactic construct (aside from literals, which denote them), they are unquestionably a semantic construct.  The semantics of popular imperative programming languages require reference to values.  Informally, we speak of "the value in a variable" or "the value this expression evaluates to".  It's difficult (and pointless) to speak of language semantics without values.''
**** Where does one "see" this exactly? You have not scientifically measured "semantics", you just invent properties of it out of your arse. And I already agreed that values are a UsefulLie, but that does not make them objective.
**** ''It appears in the semantics of elementary arithmetic expressions, and is covered almost every introductory programming textbook in ComputerScience.  As for values being a UsefulLie, that's not quite true.  At a ComputerArchitecture level, a 'value' is the generic term given to the state of a register, stack location, and/or memory address.  We say "<x> contains the value 3", for example -- which means it holds a particular string of bits, bytes, words, whatever -- and at a machine-language level we (typically) infer the type (which we '''must''' do, so that we know the value is a 3 and not a character, a pointer, the exponent of a floating-point value, etc.) by context, such as what machine language operation will use the value (or the address/register containing it) as an operand.  Once we move to a higher level language, the notion of registers and memory addresses become abstracted away, but the notion of a "value" remains in the context of variables, what functions return, what expressions evaluate to, and what literals denote.''
**** If we view program code as math, we don't need such.
**** ''Sorry, I don't follow you.  If we view program code as math, we don't need what?''
**** However, for the sake of argument, implementations typically do indeed need something value-like, whether it's called data, content, values, registers, etc.; and our collective experience of doing such by hand in math class gives us a general rough common impression of "value". However, the nature of such "guts" can be very open-ended because it is an implementation detail and there are usually multiple ways to implement the same thing. Note we can objectively all "see" the literal "3", but whether that represents a "value" is purely an internal head choice, at least in terms of the details about using and representing that "value". Again, "value" is merely a UsefulLie and the details about using "values" is NOT canonized. (I agree implementations are semi-canonized, but we shouldn't necessary define languages by implementation because it's subject to change and has a lot of efficiency-related artifacts that the language user doesn't need to be concerned with.)  -t
**** ''Implementations certainly need something value-like, and we can call that something data, content, values, etc. (but not registers -- they're containers of values) if we like, but in ComputerScience we call it a "value".  It's the term ComputerScience uses to collectively describe what variables (and registers and memory addresses) contain, what functions return, what expressions evaluate to, and what literals denote.  Individual programmers' usage may deviate from this terminology, and some language documentation may deviate from this terminology, but the science that underpins programming -- ComputerScience -- is consistent in its terminology.''
**** If by "consistent" you mean common patterns by implementers, I may agree to some extent. But that's not the same as a canon. It's not logical to define non-implementation terms by implementation because implementation is swappable. The exact nature/terminology of "types" and how "types" are associated with "values" and "variables", in particular, is ambiguous, as some of the examples in this and related pages illustrate. And terminology is typically determined by usage, '''NOT by "computer scientist high priests"'''. Besides, there is no central authority in CS in the Catholic sense even if they ''were'' given such authority. It strongly appears as if you are forcing canons where there are none.
**** ''There are "common patterns by implementers", but that's not what I meant by "consistent".  What I mean by "consistent" is that ComputerScience consistently uses certain terms to describe aspects of popular imperative programming languages.  The "exact nature" of types and how types are associated with values and variables is not ambiguous in ComputerScience terms, and indeed every example here (and on related pages) that attempts to demonstrate such ambiguity has been answered with a description that disambiguates it in introductory ComputerScience terms.  Whilst that terminology is not "canonical" in a strict sense -- i.e., dictated by official canon -- it's canonical in the usual loose sense: we (as ComputerScientist''''''s and SoftwareEngineer''''''s) have tacitly agreed on certain terminology and try to stick to it in order to facilitate communication.''
**** PageAnchor BiasPath01
**** It's been made fairly clear to me based on examination of YOUR interpretation of certain textual passes you have quoted that you inject your personal interpretation into such text regardless of alternative ways to interpret such text. For example, if there were 3 possible ways to interpret a given phrase, you would insist YOUR way is the ONE RIGHT WAY and that your way is the clear and obvious way to interpret it. In short, '''you see what you want to see'''. I honestly believe you are a highly biased person and you are thus unreliable when it comes to interpreting English text. Sorry, I cannot find the sub-topic I had in mind for linking to illustrate this. If I encounter it later, I'll add the link. -t
**** ''You're free, of course, to believe what you like.  However, my descriptions are simply the conventional introductory ComputerScience descriptions for language semantics.  It's the same stuff you'll hear in any first-year programming language course.''
**** As written, they do not define EXACTLY what a "type" is and EXACTLY how it relates to "value", especially in dynamic languages. I've invited you many time give an UNAMBIGUOUS definitions of "type" and "value" and UNAMBIGUOUSLY describe the relationship between them. You seem to waffle between claiming English is not sufficient to claiming it is. PageAnchor human_languages_26 appears to be where you were in your "English (as usually used) is insufficient" mode, but above appears to be flippage. 
**** ''A type is a set of values and zero or more associated operators.  A value is a representation (see ComputerArchitecture) and a reference to a type.  A variable is a time-varying reference to a value (plus a static reference to a type, if the language is StaticallyTyped.)  A constant is a static reference to a value.  An operator is a function (see mathematics) that accepts zero or more value operands and returns a value.  A literal is a sequence of symbols that denotes a value.  Have I missed anything?  At this point, if you have sufficient exposure to programming languages, we normally illustrate these definitions by showing how they apply to an assortment of popular programming languages.  If you lack that experience, we normally illustrate it using the language you're being taught.  If you're unhappy with those informal, introductory ComputerScience definitions, then the next step toward rigour and unambiguity are formal definitions using formal notations.  That's what human_languages_26 suggests.  Of course, then it's no longer introductory ComputerScience, it's intermediate ComputerScience.  For understanding types more formally, the Cardelli papers are a good start.'' 
**** Sigh. We've been over these already. "Associated" is not Boolean (except maybe beyond the light-speed event horizon of the universe). Those definitions '''are fuzzy''', and Cardelli does NOT offer clear definitions, only models (which also are not canonical, by the way). I'm tired of debating willfully stubborn anti-scientific people.
**** ''Yup, we've been over those already.  Those are the introductory definitions, lacking only the usual bucket of code examples.  They're not fuzzy to me, or to my colleagues, or to the others who occasionally weigh in on these threads.  If you don't get it, you don't get it.  Though I've never encountered the like before.  I've been going through the same concepts with 1st year ComputerScience students for the past four weeks, just as I've done for the past 11 years, and except for the inevitable handful who don't understand programming at all and find everything difficult, they understand it.	You're unusual in that you can clearly code, but these fundamental concepts -- which even the weaker coders pick up -- seem fuzzy to you.  I don't know what to suggest.  Do you think loads of code examples and exercises, like we go through with the students, would help?''
**** Arrrrg! They are "not fuzzy to [you]" because you inject your personal head model into them and pull out a mirror of your personal interpretation. It's a '''Rorschach chart''' to you: your head shapes any vagueness into your pet preference model as I have discovered by probing you.  (And I cannot sample your colleagues to verify your match claim). If there was truly clear definition, then it would be refined into an algorithm-like device, math formula, rule set etc. to test objective objects against the definition to say "yes, X is a Y" and more importantly, "no, X is NOT a Y, per rule 38". You don't even begin to approach such rigor, not even on the same planet as such a test.
**** ''It '''is''' that easy to test against the definitions, as can be trivially demonstrated by identifying variables, values, types, operators, associations between operators and types, and constants in the syntax and semantics of any popular imperative programming language.  Automating it with an "algorithm-like" device is straightforward, too -- in fact, we do it all the time, and we call that "algorithm-like" device an "interpreter" or a "compiler".''
**** Yeah, and there are multiple '''different''' ways to run/emulate/model the same language (IoProfile), like the tag model and the ExBase interpreter writer you had a run-in with for putting the type tag "in" the variable. You should have anticipated I'd point out such by now, we've burned like 7 pages on it. Are you forgetful or do you just like repetition?
***** Addendum: '''I didn't invent the "variable" modeling''' approach in my model; I copied the idea from another system I once saw on a VAX minicomputer (the details of which escape me). I found it a clever and parsimonious metaphor/technique for modeling the guts of an interpreter.
**** ''Sure, there are multiple ''possible'' ways to present the same thing, but ComputerScience has converged on one -- the one I described -- which is also, perhaps, the simplest.  If I describe your tag model using text isomorphic to that which I used above, I get: "A type is a tag <otherwise undefined>.  A value is string of bits.  A variable is a time-varying reference to a value and a tag (plus a static tag, if the language is StaticallyTyped.)  A constant is a static reference to a value and a tag.  An operator is a function (see mathematics) that accepts zero or more value-and-a-tag operands and returns a value and a tag.  A literal is a sequence of symbols that denotes a value and a tag."  Essentially, that's the same as the "standard model" (if we can call it that) with a bit more complexity surrounding variables (two type/tag references?), and a "value and a tag" that shows up so consistently that it begs for a single term. It also relies on nuanced definitions of "value" and "type/tag", which makes it a PrivateLanguage.  That's fine if you can convince others to share your PrivateLanguage, but given there are already well-established terms in this area, it's going to take some work.''
**** That there may be academic tendencies I don't dispute; however the frequencies are not tagged and documented nor officially "blessed" by any standards body. Any tendencies found are '''soft tendencies''' such that it's not worth trying to force them into a standard. It's not something to get one's undies in a knot about. Live with the fuzz. And optimizing such for 1) human language (English), 2) actual implementations, and 3) emulation/experimentation/prototyping models probably involve selecting different trade-offs among each such that no one choice set will make all 3 happiest at the same time (or be personal design preferences). I do suspect much of the literature is optimized for the #2 because it is written by those who work on #2 as a job.
**** ''I'm not clear how your response follows from my point, or what point it's trying to make.  Sorry.''
**** I guess I misunderstood your point then. Regarding a PrivateLanguage, it's not an issue because there is no public language as a competitor. Humanity's current choices are PrivateLanguage or zilch.
**** ''There is certainly a public language that ComputerScience and SoftwareEngineering use, with terms like value, variable, type, constant, and literal.  You may not agree with those terms or what they mean, but that's your personal view.  Independent of your view or mine, those terms are the public language.''
**** No no no. You are putting words in my mouth. I didn't say I don't agree with them. I say they are VAGUE and/or ambiguous. Big difference. Any claimed rigor has so far been somebody's PrivateLanguage. If you see definitions you personally like, you label them as "good". If you see definitions/usage you don't like, such as Php's ("type of variable" above), you claim it "wrong". That's how you mentally shape the world to fit your own personal preference. Just admit it, you have a bad habit in that department. Admission will free your mind. Let go.
**** ''Except they aren't vague or ambiguous.  If they were, we wouldn't be able to design languages and build interpreters and compilers that implement them.  And PHP's "type of variable" is certainly wrong.  How else would you explain that gettype("fish") works?  Is "fish" a variable?  I'm sure there are confused programmers who would say it's a variable -- and obviously there is a confused technical writer who (sort of) did -- but no ComputerScientist or SoftwareEngineer would.''
**** Language designers get to define and/or implement the terms how they see fit for their language. But their views on that only live in their own language (or at least their docs), not the entire universe. For an analogy, if I make my own Star Trek game, then my stories, look, and characters would reflect MY OWN VIEW of the Star Trek universe, and would not "be" the official canon. I would be '''projecting my personal view''' of Star Trek into my virtual universe (game). Interpreters are similarly a "personal universe" that "implement" one person's/group's view of various existing notions.
**** ''Sure, language designers can call parts of their language whatever they like.  However, ComputerScience and SoftwareEngineering both take a broader view of programming languages in general -- and use terminology independent of whatever is found in reference manuals -- based on recognition of both syntax and semantics typically found in popular imperative programming languages.  It's that recognition which allows me -- and others -- to trivially see that the PHP manual has mistakenly called values "variables" in various places in the manual. ''
***** You keep claiming "computer science" makes clear definitions of such, but '''repetition does not make truth.''' You Are Wrong.
***** ''You keep disclaiming that ComputerScience makes clear definitions, but that doesn't make it so, either.  Obviously, repetition does not alter truth.  However, ComputerScience '''does''' provide clear definitions of variable, value, type, literal, and so on, and they're the (introductory) definitions I've provided above.  Look in introductory programming textbooks, introductory ComputerArchitecture textbooks, and introductory ComputerScience textbooks to see that their definitions accord with mine.''
***** Whenever we go over such text, it typically leads to the same kind of situation that led to the discussion just before PageAnchor human_languages_26. Multiple interpretations are usually possible. Regular English is just too vague, and more formal approaches appear to be selecting one model out from multiple possible models that "do the same thing". In other words, '''all attempts at explicitness have made arbitrary "implementation" decisions'''.
***** ''Interpretations are irrelevant.  What we're talking about are descriptions of semantics -- descriptions of what the parts of languages are intended (by their designers) to do in interpreters and compilers -- not descriptions of interpretations of what developers think they might do.''
***** Terminology is determined by "the masses" or by a group within the group, not directly by interpreter builders. We had 3 or so page of debate on that already. I don't want to reinvent that fight here. Note that we know of at least one interpreter implementer that used something closer to my version of "variables".
***** ''In a technical or scientific field like SoftwareEngineering or ComputerScience, the terminology casually employed by technicians in "the field" is irrelevant.  As for the "interpreter implementer", if it's the individual I think you're referring to, his variables had a type attribute because his language supported optional static typing.  However, it's hard to tell if that's what he meant because his descriptions typically involved such an undifferentiated muddle of theoretical, implementation, and AdHominem content that his writing was difficult to understand or give any credibility.''
***** I'm not sure I agree its "irrelevant" because language (terms) is ultimately determined by actual usage, for good or bad. Either way, there is still no known definition that is both clear and not arbitrary (in terms of selecting one of multiple models).
***** ''There may well be informal "field" terms in use, but if those terms differ from those that the underpinning science uses formally, then the formal use is the only relevant one.  Vernacular is irrelevant.''
***** "Underpinning" my ass. Fucking Bullshit! '''THERE IS NO CANON!'''

***** I'll agree that ''syntactic'' elements in common languages have a lot of congruence, but "values" and "types" are either not them or do not have direct syntactical elements, or vary more widely than the others. There is no syntactic equivalence of "value" in Php and JS, for example. Literals often represent what we call "values", but there are other things/situations that are called "values" that have no objective/visible literal associated with them. We can make objective statements about syntax and syntax-based definitions [1], but not "hidden" parts.
***** ''Every program language is defined in terms of syntax (which is directly "visible") and semantics (which are not directly visible, at least not like syntax -- though when you mention syntactic congruence, what you inevitably mean is that the same syntax maps to the same semantics for multiple languages.)  Every popular imperative programming language has some significant syntactic differences and some significant syntactic similarities.  Every popular imperative programming language has isomorphic semantics around values, variables and types, differing only in the ways described by TypeSystemCategoriesInImperativeLanguages.  If there is some purported difference in semantics (around values, variables, types, literals, constants, etc.) in some popular imperative programming language, then you should be able to identify it, and:''
****** ''If I can explain the purported difference in semantics in terms of the explanations on TypeSystemCategoriesInImperativeLanguages and/or the usual definitions of value, variable, type, literal, constant, and so on, then it's evidence of consistent semantics. Any apparent "difference" is then only attributable to a deviant language manual, some misunderstanding, etc.''
****** ''If I can't describe the purported difference in semantics in terms of TypeSystemCategoriesInImperativeLanguages and/or the usual meanings value, variable, type, literal, etc., then maybe it's the start of evidence that we can't make objective statements about the "'hidden' parts" -- or at least can't do so in any general sense.''
****** We can objectively measure syntax and language I/O (IoProfile), but nobody has shown a proven objective way to measure "semantics". I do not consider "semantics" an objective thing: it's in the head; and '''different head models can provide equivalent (or GoodEnough) predictive value'''. You can pretend it's objective until the cows come home, but the cows will die far far away. The above implies that English is explicit enough to do "difference math" on. Not. English is not math, and if you try to use it as math, you'll injure your spleen.
****** ''Semantics aren't "in the head".  They're what the parts of language do in relation to each other and the underlying system.  Semantics aren't "in the head" any more than what valves and pistons do in an engine is "in the head".  Airflow and combustion and compression and exhaust aren't "in the head", even though you can't point at "the compression" in an engine.  They're fundamental to the operation of the engine; they're what make it do useful work.  Likewise, semantics are what make a language do useful work.  As such, we don't measure semantics, we design semantics.  They're created.  As it turns out, language designers have designed all the popular imperative programming languages to use the same (FORTRAN-derived via Algol, or via Lisp) semantics.  That's why a = b + c (or a := b + c, if you're using Delphi) has the same semantics -- aside for variations in terms of TypeChecking described in TypeSystemCategoriesInImperativeLanguages -- in every popular imperative programming language.''
****** Your mechanical analogy is largely inappropriate to interpreters/compilers in the same way we don't talk about stacks when talking about expression evaluation even though many of them use stacks "under the hood". Re: "we don't measure semantics...", yeah that's your problem. That such languages have a similar IoProfile, I don't dispute, but that's not a sufficient proxy for "semantics".
****** ''My mechanical analogy is intended only to illustrate that semantics aren't "in the head".  The "semantics" of an engine -- what pistons, valves, cams, crankshafts, compression, exhaust, power stroke, etc. mean or do, and noting that "compression" isn't part of an engine, just like values aren't part of language syntax -- is independent of our interpretation.  Interpretation of semantics is "in the head", but semantics themselves are what the parts of a language do by design.''
****** Why you chose "compression" as a comparison to "values" escapes me. It's an odd analogy for the topic. Compression can be objectively measured with instruments anyhow. I still reject your claim that semantics are objective (at this point in history).
****** ''I chose "compression" because it's not an engine part, but it's fundamental to the working of an internal combustion engine.  Likewise, "value" isn't a syntactical part, but it's fundamental to the working of a popular imperative programming language.  As for rejecting my claim that semantics are objective, feel free to reject all you like.  That doesn't make you correct, and it certainly doesn't present any evidence in favour of your opinion.''
****** It's not objective by default. Even if I got hit by a bus, you still have no evidence it's objective. We can measure compression, we cannot measure "values" in any consistent way, unless an arbitrary model is selected.

**** And I have agreed above that the Php doc on "gettype" is wrong, but not necessarily for "settype". Perhaps they wrote the description of "settype" first, and then copied it over to "gettype" and modified it without thinking.
**** ''Perhaps.  Though confusing values with variables appears throughout the manual.''
**** Per clear faults, or per your opinion based on your preferred mental model? The "settype" page is not wrong in any clear sense.
**** ''Per example #1 on http://php.net/manual/en/function.settype.php it changes the value. Note that the value in $foo has changed from "5bar" to 5; clearly a change in value according to the standard model.  The name is perhaps derived from what is called a "typecast", "type conversion", or "coercion" in various programming languages, which converts a value of type <x> to a nominally corresponding value of type <y>.''
**** A "change in value" is not necessarily mutually exclusive with a "change in variable". Thus, the first happening does not automatically preclude the second from happening. Thus, your logic is flawed. I suggest you take a basic course in Logic. You appear to be weak in that area. A a skillful logician would have caught and/or addressed the mutual-exclusive assumption themselves. It would be almost a reflex to test it first.
**** ''Can you find a popular, imperative, dynamically-typed language where you can change (or even set) "the type of a variable" such that it '''requires''' that the variable possess a 'type' attribute independent of a 'value' attribute?''
**** Why is "required" required? I don't understand the purpose of the question. Actually, I don't understand the question, period. Different models can match the same behavior; I never claimed there was one model.
**** [Why use a model that adds unnecessary extraneous components - such as "the type of a variable" distinct from "the type of a value" - when the relevant behaviour is readily explained by the conventional model, which does not require such components? -DavidMcLean]
**** ''Exactly.''
**** It does require the components, they are just packaged and/or labelled differently. Anyhow, I explained the rational of my design multiple times in related topics as carefully and as detailed as I could. I won't reinvent those debates and descriptions here. In short, we ended up disagreeing about how to measure parsimony, WetWare assumptions, and the ultimate goal of the model.
**** ''A variable only "requires" an explicit type-reference attribute because you're insistent upon using a nuanced, PrivateLanguage definition of "value".''
**** But there is no PUBLIC one, such that a PrivateLanguage is all there is. '''THERE IS NO CANON!''' Say it a billion times but there still is none.

**** ''Interpreters are not physical things?  How so?''
**** They are not. That should be obvious. They may have physical representations, but that's comparable to writing E=mc^2 on a piece of paper.
**** ''You can't execute E=mc^2 until it's implemented in a program or a device.  Then it consumes energy to run and can indirectly cause physical changes on storage media and in the state of various electronic devices.  An interpreter does the same.  That sounds rather "physical" to me.''
**** This is growing into a convoluted word game. I don't see how your plane analogy applies to the tag model. If the model is "wrong", where does this wrong-ness manifest itself? Where's the plane crash?
**** ''I've shown several times how your model fails to account for operator invocations.''
**** Sorry, doesn't ring a bell.
**** ''I'm sure it must.  We've gone over it several times, though perhaps your "anonymous variables" were introduced to address it?''
**** You appear to be making up fake problems.
**** ''What "fake problems" am I making up?''

*** This may be getting back around to EconomicsOfAdvancedProgramming. Programming is a relatively "fast burn" career. Age discrimination, RSI, and burnout often limit ones time as a programmer. It's not a "career" field. A longer-term view may not be warranted when compared with all the alternative expenditures of time. You need to make a more explicit economic case, as discussed in that topic.
*** ''The notable "longer-term view" is that employers are increasingly unlikely to recruit programmers without degree-level ComputerScience or SoftwareEngineering education, because it's cheaper to bring in programmers with the right knowledge and skills than to train them later or (worse) put up with their mistakes.  That's happened already in every other skilled field, where there's a clear progression from certain education and degrees -- and only those degrees -- to specific career routes.  Educated programmers will inevitably be schooled in values, variables, and types.''
*** Also, the vocab of the '''guts of interpreters is arbitrary'''. In the future, interpreters may be implemented differently than they are today (assuming your description of their construction is accurate). Thus, it's poor form to say that any one prediction model is "worse" than the other. All else being equal, yes, go with tradition. But it's not equal.
*** ''Values are fundamental to mathematics and ComputerScience, independent of (but obviously influencing) interpreter internals.  As long as languages are designed to perform calculations, values aren't going to go away.''
*** Prove that values objectively exist and always have the properties you claim they do. Do it under ValueExistenceProof. Anyhow, I'm willing to dispense with the "value" attribute in my model to avoid the controversy if you can find a reasonable and reasonably short alternative. "Representation" is too long.
*** ''The problem isn't the "value" attribute of your "anonymous variable", the problem is your model of certain dynamically-typed languages: You associate types with variables, which is wrong, and your values are called "anonymous variables".  (I'll leave "tag" out of it, for now.)  How is "representation" too long?  Too long for what?  Too many syllables for your target audience to read?''
*** It's meaningless, unfamiliar, and long. 3 strikes against it.
*** ''So leave out "representation".  It's not critical.  My early examples at the top of TypeSystemCategoriesInImperativeLanguages glossed over it, much as most language references gloss over it.'' 
*** For clarity, I want a '''named slot''' to stick the "representation" into. Good documentation names/ID's the parts of the model.
*** ''Then call it "representation".  That's what it's normally called.  Why are you concerned about the length of the term?''
*** Normally called such where? I didn't say length was the only concern. It does poorly in 3 categories.
*** ''It's common usage.  Google for 'value representation in computing' or similar.''
*** My google browsing does not show it's common, at least not in a consistent, coherent way. I tried "value representation in interpreters".
*** ''Try 'value representation in computing'.  At least the first ten hits use it in a manner consistent with the way I've used it.  After that, I didn't bother looking further.''
*** It talks about byte-level "encoding" of information. And sometimes it also uses "data representation" instead. We don't need to model at that level for the stated goals.
*** ''That's exactly what the representation is -- a byte-level "encoding" of information -- and "data representation" is a synonym.  We don't need to model its specifics, but its presence is necessary in every language.''
*** But colloquially among programmers, it's quite often called a "value", far more often than "representation" in my experience. This is largely because programmers rarely see ACTUAL "representation" inside the machine/chips. They see the I/O. Even debuggers often don't show hex or binary versions, at least not without explicit commands/modes; and that can all change in different versions/vendors; which is why I don't define languages by specific implementations of internal "representations".
*** ''Colloquially among programmers, values are called values.  A value's representation (remember, a value is modelled as pair consisting of a representation and a type) is generally not considered, since for most purposes it doesn't matter, though it's perhaps most likely to come up in conversation about floating point, where "float" is the type and IEEE 754 defines its representation.  And strings, too.  It's mentioned in discussion about strings, such as whether they're represented as ASCII bytes or UNICODE, or whether they're null-terminated or length-preceded.''
*** That's often called "encoding" in developer circles. But generally it's not a concern for most type-related issues. I don't want to drag bit-diddling into the model except as a last resort.
*** ''Yes, "encoding" is another synonym for "representation".  It's true that you can generally ignore it, but if you want to model a value, you either need to show that it has a representation or encoding, or you'll eventually have to do some HandWaving about it.''
*** If and when it becomes a demonstrable problem in my model, I'll revisit that.
*** ''Then you're taking the "ignore it" route, yes?''
*** Ignore a problem that hasn't been demonstrated to exist? See note 1 in TopsTagModelTwo.
*** ''I'm not saying there's a problem per se -- you can, after all, ignore the representation.  However, given that a value '''is''' a pairing of a representation and a type, it will inevitably become an issue at some point.  Someone will ask about it.''
*** It "is" in YOUR model; not all possible models. (Well, it may be in your model; it's hard to tell since it's hard to follow.)
*** ''Actually, it "is" in programming languages implemented on real computers, and is fundamental to implementing programming languages on real computers.''
*** Working with 1's and 0's is indeed fundamental to implementation. But we don't necessarily want to deal with that level in abstractions meant for specific purposes. 
*** ''As I said, you can ignore the representation.''

** ''That said, how about this for Category D1:''
	1. Let S be a character sequence, which is an ordered collection of characters from a character set
	2. Let T be a type, which is defined here to be a set of character sequences T = {S1 .. Sn}
	3. Axiom: For every S, there exists at least one type T such that S ∈ T, or S is considered invalid
	i.e., every valid S is an element of at least one T
	4. Let V be a value, defined as V = (S, T) such that S ∈ T
	5. Let C be source code for a program, which contains character sequences S1 .. Sn
	6. Let M be the computer memory in which a program C runs
	7. Then, for every Si in C, the interpreter finds a T where Si ∈ T and converts Si to a value Vi in M such that Vi(T) = T and Vi(S) = Si
	8. Then, given a value V(S, T) in M and a type T, program C can determine if V(T) = T or V(S) ∈ T
.
** ''An example of #8 is is_numeric() in PHP.''
** ''Language Category D2 is:''
	1. Let S be a character sequence, which is an ordered collection of characters from a character set
	2. Let T be a type, which is defined here to be a set of character sequences T = {S1 .. Sn}
	3. Axiom: For every S, there exists at least one type T such that S ∈ T, or S is considered invalid
	i.e., every valid S is an element of at least one T
	4. Let V be a value, defined as V = (S)
	5. Let C be source code for a program, which contains character sequences S1 .. Sn
	6. Let M be the computer memory in which a program C runs
	7. Then, for every Si in C, the interpreter converts Si to a value Vi in M such that Vi(S) = Si
	8. Then, given a value V(S) in M and a type T, program C can determine if V(S) ∈ T
.
** ''An example of #8 is cfArgument in ColdFusion.'' 
* ''Is it?  TypeChecking is about ensuring that the "parts" of a program have been combined in meaningful ways, and/or prevented from running (via "type mismatch" errors and the like) when meaningless combinations are attempted.  This is fundamentally about checking '''code''' for correctness.  Validation is about checking the running program's '''input''' for correctness.  These operations can sometimes overlap, especially in dynamically-typed languages, but "overlapping" is not the same as "fuzzy".''
* Almost none of the so called "type checking" in many dynamic languages checks code for correctness.
* ''It ensures correctness.  It ensures that operators matching operand types are invoked.'' 
* Is ALL "ensuring of correctness" about "types"? If not, what are the precise damned rules for when checking "is" types or "is about" types etc.?
* ''No, only for ensuring correctness related to types.  Look for the type references and see where they are used for TypeChecking.  In imperative programming languages, this normally occurs when performing variable assignments (statically-typed languages) and invoking operators (all languages).''
* You appear to be using circular reasoning: "You know they are for types because they are for types".
* ''Sorry, not following you.  What part is circular?  Type references '''are''' used to support TypeChecking.''
* "Type" is vague and so is "type checking".
* ''Repeating an allegation does not make it true, and if it was true, programming languages could not be built.''
* How does that follow? One can call something a "type" or a "ziffglerp" in a given model and it has a clear meaning or role within that little universe, but that doesn't make it universal.
* ''It doesn't matter what it's called; "type" and TypeChecking concepts are sufficiently concrete that programming languages are designed and built that employ them, and that's about as concrete as something can get.''
* "Country music" is concrete enough that artists can play and compose "country music" when they so desire, but that doesn't make it a rigorously defined concept.
* ''Indeed, and that's all the "concrete enough" we need to build languages, too.  Anything more rigorously defined than that is up to the language designer.''
* Right, so we need per-language models and a "kit" of patterns and techniques that helps us build such models. I prefer to build them out of data-stricture-like representations and imperative step-by-step algorithms to leverage programmer familiarity with them; but you choose an English (verbal) centric approach, which I feel is a mistake, or at least greatly limits your audience.
* ''I don't think we need per-language models, just better language documentation.''
* At least the "configuration" of the models is language-dependent.
* ''What does that mean, exactly?''
* I'll focus on specific examples for specific languages/operators for now. Factoring into a generic framework can come later.


An "association" then exists similar to what one would find in a relational schema. Then if the code "executes" a function such as isNumeric, CF would do a lookup in such tables. Granted, it's not a resource-efficient way to implement isNumeric and similar operations, but technically would work. '''Look-ups (set membership) can often be traded for computation (such as parsing)''' and vice verse in implementations such that it's not a distinguishing feature, or at least not a reliable feature to tie models and language descriptions/manuals to. Relationships can be "stored" or calculated/computed as needed and the decision of choice is often a matter of resource efficiency, not a feature of what the I/O looks like (observable behavior to the programmer).

''That is true.  As implementation strategies, the above are certainly feasible, and you're right that parsing is not a distinguishing feature.''

And that kind of "associated with" (parsing like) often behaves different than the tag kind of "associated with", and '''"associated with" alone does not distinguish between the two'''. For one, there is one and only one association in the tag flavor with the variable, and the model makes that clear via a data structure (XML) that makes quantity limits clear and instantly perceptible to the reader. 

''In the phrase "x is associated with y", it means that given x, you know y or can answer questions about y.  If the relational model appeals to you, imagine that x is the primary key and y is an attribute value.  Whether y (meaning a type, in this case) is "parsing like" or "the tag kind" (?) is irrelevant, except where explicitly stated as I have done in TypeSystemCategoriesInImperativeLanguages.''

''If the phrase "a variable is associated with a type" is used, you can safely assume that any distinction between "parsed" vs "tagged" or whatever is irrelevant, and the only important factor is that a variable is -- somehow, and we don't care how -- associated with a type.''

By "instantly perceptible", I mean they don't have to remember that rule from 20 pages back; it's still there, visually presented in the key data structure(s) of the model. If one has a photographic memory, than such "rules" stated in English are sufficient. But a good many developers don't have photographic memories such that a quantity rule like that is best represented in something more visual or easier to remember than a buried English rule. My model is to be human-friendly, not machine friendly. Your brain may easily store and catalog bunches of verbal rules like "all zogs are floogs except if the zog has a nib on Thursdays that correspond to gliggs...", but you cannot extrapolate that ability to all humans. A diagram or data structure in a familiar format (XML, relational, etc.) simplifies the absorption and recall of such rules, associations, scope ties, and quantity limitations.

--top

''Obviously, there's nothing wrong with diagrams and illustrations, but the verbal explanations on TypeSystemCategoriesInImperativeLanguages are equivalent.  If they don't appeal to you, that's fine.  Feel free not to read them.  Note that TypeSystemCategoriesInImperativeLanguages includes ASCII diagrams and XML for those who prefer them.''

It lacks the "mechanical" links between the text and diagrams, per above.

''What do you mean?''

[Verbal descriptions deemed "equivalent" is like saying that a verbal description of a real landscape is "equivalent" to the landscape (or a picture thereof) itself.  Not likely.]

''Of course not, but if I describe a blue square inside a green circle, and draw the same, then my verbal description and my diagram are equivalent -- at least in the salient details.  That is what was meant by "equivalent", above.''

Consider:
* TheMapIsNotTheTerritory
* AllModelsAreWrongSomeModelsAreUseful
----

[1] An example of an objective statement about terminology and syntax could resemble, "Out of the top 100 most popular languages, 85% call the following syntactic pattern [insert RegEx here] a 'foo', per their published syntax diagrams."

''Notably, out of the 10 most popular imperative programming languages as of this writing (per the TiobeIndex: C, Java, Objective-C, C++, C#, Basic, PHP, Python, Perl, and Delphi), 100% have the same syntax for assigning a value to a variable bar the symbol used for assignment (it's ':=' in Delphi, '=' in the others) with semantics as described in TypeSystemCategoriesInImperativeLanguages.''

In rough sense, above the level of the our disputed areas, I agree.
----
Related evidence discussion at CertaintyIsaSmell.
----
Basis:
WhatIsSemantics
----
See also: VagueOrArbitrary
----
OctoberThirteen