This is the illustration of the different ways dynamic languages could potentially interpret this statement: writeln("34" + 34); The purpose is to demonstrate all the potential different ways it could in theory be done, yet be an otherwise "normal" looking language. '''Language #1''' The language (interpreter) looks at the type tag of the right to determine the "assumed type" of the entire expression. In this case the tag is "Number" (or similar) because the expression has no quotes. It thus sees if the left side can be interpreted as a number (via parsing, not tag analysis), converts it to 34 internally and does arithmetic addition to get 68. '''Language #2''' The language looks at the type tag of the left to determine the "assumed type" of the entire expression. In this case the tag on the left expression is "string" because the expression has quotes. It thus assumes string concatenation, converts the right-side number to the string "34", and the result is "3434". '''Language #3''' A language looks at the type tag of the first operand, and sees "String" (since it is enclosed in quotes). It then looks at the 2nd operand's type tag, and sees "Number" (because it has no quotes). In this particular language, the tags must be of same type (same tag), or an error is thrown. Since "String" is not "Number", an error is thrown. '''Language #4''' A language looks at the type tag of both operands. The first is "String" and the second is "Number" (per above). This particular language has a rule-table like this: Oper A | Oper B | Assumed Type --------------------------- String | String | String String | Number | String Number | String | String Number | Number | Number Since it matches the 2nd rule row, String is assumed, and thus concatenation is assumed and the result is "3434". '''Language #5''' A language parses both operands. If both can be interpreted as a number (irregardless of tags or quotes), then addition is assumed. If either side fails to parse as a legitimate number, then string concatenation is assumed. In this case both sides "pass" and the result is 68. '''Language #6''' A language sees if the first (left) operand is parsable as a number (irregardless of tags or quotes). If it passes "numberness", then addition is assumed, else concatenation. However, if the second operator cannot be converted to a number (including via parsing), then an error is raised. In this case it's already a number such that the result is 68. (Note that "34" + "34" would also return 68 because parsing would be done if the second operand was not a "native" number.) '''Language #7''' The language performs the operation on the operands interpreting "+" as addition being that it has operators for concatenation. In the example case, the result would be 68. Languages in this category take the view that if anything is passed to a process it is appropriate to the requirements of that process - i.e. there is no error. If there is in fact erroneous data then the process should fail gracefully. Concatenation is a different operation and would be something like writeln(concat("34", 34)); which would produce "3434" TopMind believes that any variable or constant with a tag (primary type) of "string" is parsed to see if it's a number. If it cannot be converted into a number, then an error is raised. In the example case, the result would be 68. If the first operand was "3A" instead of "34", then parsing to a number would fail and an error would be raised. And well that may be true for some language unknown to me, but I reckon the process just fails when it tries to add a string to a number. * You are thinking of variation number 8. Variation #7 attempts to "interpret" the operands as numbers. (I should clarify that for the 2nd operand also.) And what you do mean by "languages in this category"? And I'd appreciate it if you don't delete my text if you disagree with it. I put your original at the bottom of this page instead of outright delete it, and expect the same courtesy. (Granted, I should have put a marker in the original place describing the move. My bad on that.) -t ** I added variation 7 - somebody else added 8. 7 and 8 are the same, so I would delete 8. I won't in case you wrote it. You should since you agree. And I deleted nothing of yours. I respectfully if a little reluctantly (since it is nonsense) copied your text and placed it below the original, rather than leaving it where it changed what I described as variation 7. You deleted my text, not the other way around. Are you deliberately trying to obfuscate it? And why, if so? *** There seems to be some confusion here. I'm pretty sure I created #7, but rather than fight over that, maybe we can find a mutual description. My intent is that #8 checks the equivalent of Php's getType() operation on each operand (tag check), and if either one is not a numeric type, it raises an error. #7 would run the equivalent of Php's is_number() on each operand (value check), and if either comes back False, then an error is raised. Otherwise, both operands are parsed/converted to numbers and added together. Essentially #8 must have "native" numbers but #7 will accept foreign born converts "number-able". (Php's "+" is overloaded with concatenation, but the hypothetical language for #7 and #8 is not.) -t ''Note:'' Since some do not like my usage of "tag", for this example when I say "tag", you can interpret it to mean the "type" that the quotes indicate. Thus, if a value (constant) has quotes, its tag is "string", but "number" if it does not have quotes. In the tag model, most dynamic languages will set the "tag" based on existence or absence of quotes. (Other syntactical elements may also play a part, depending on the language, but we'll put these aside for this example and just consider "number" and "string".) '''Language #8''' This language doesn't do any type conversion (such as parsing to "interpret as") for this operator (unlike #7), and "+" means addition and it has a different operator for concatenation (no overloading). The code as given would trigger an error because the tag of the first operand is not a numeric type, per tag. {Tags? Both languages 7 and 8 describe a type-handling style which, to me, describes dynamic languages in the context of conventionally typed languages. In dynamic languages, ("true" dynamic languages?), the type of each variable or literal is implicit, not in the definition of the variable, but in the context in which the variable is used. If a function is used, it expects the caller to have passed it valid data. If the data is not valid, the function used would either trigger an exception, or happily use the erroneous data. There are times when this can cause difficult to find errors - for example, say a process had an error which allowed non-numeric data to be passed, say, say to an addition process. I would expect an exception to be raised. However if this data were, coincidentally, a representation of a floating point number, like a product code of "123E05", the addition process would not fail and you could have a subtle (difficult to see) problem within your system.} ---------- I am reminded of this talk, which makes fun of types in JavaScript and Ruby: http://www.destroyallsoftware.com/talks/wat ''Epic.'' (I cannot play the vid. Tried 2 browser brands.) ''Odd, that. It works on everything I've got, including some mobile devices. Firewall issue, maybe?'' --------- The above is speculation. * What do you mean by "speculation"? Speculating on what? They are not necessarily actual languages. I'm just illustrating the possible ways to implement "+". -t * ''You're guessing about how languages work. I describe how they work, without guessing about it.'' * No. I'm ignoring implementation tradition, per below. I'm only considering the possibilities, and '''worrying about implementation later'''. If you can prove that one is not possible or too confusing to most programmers, then I'll revisit it. * ''It's quite evident you're guessing, without knowledge of how operator dispatch is typically implemented. You appear to want to call that "ignoring implementing tradition", but that's obviously not your motivation. And it's definitely confusing and certainly doesn't reflect real languages. "Rule-table"??? Checking to see whether there are quotes??? In a peculiar and highly distorted stretch of reality, you could perhaps argue that these things exist or happen, but you gain no explanatory clarity or power by creating such fictions given what really happens is so simple.'' * Again, I am NOT cataloging implementation. Thus "knowledge about how they are typically implemented" is meaningless. Nor am I trying to educate regular programmers about "actual" implementation. (At least it's not a top goal.) * ''Then what are you trying to do?'' * Illustrate all the possible "processing" variations dynamic languages can have, and possibly serve as a baseboard for future examples. * ''You wrote (for example) "A language looks at the type tag of both operands." That sounds like a description of implementation, rather than a description of behaviour or "'processing' variations".'' * It's a shortcut for "acts like" it has a tag. We've been over visualization already I thought. * ''The phrase "has a tag" implies an implementation strategy, because "a tag" is otherwise undefined. A phrase like "is an integer" or "is of a given type" does not.'' * "is an integer" doesn't tell us anything specific enough to predict output or form models. It's a fuzzy head notion. As pointed out before, operations like typeName() may seemingly contradict "isNumber()" in terms of "is an X". Thus, they are NOT CLEAR by themselves. And "tag" is something internal to the model: it does not have to be defined in general, just in terms of the model: just like "epicycles" in the epicycle planet model (which technically can be made to forecast accurately, by the way.) * ''What does "is a tag" tell us that "is a type" or "is an integer" does not? Why would we use epicycles instead of orbits?'' * Outside of a model, perhaps nothing (clear) in either case. And I am not saying epicycles are "better than" other models, only pointing out that they have meaning WITHIN the model. They are a part in the model's construction and may not correspond to anything outside of the model. Yet a model with PrivateLanguage parts can STILL forecast accurately. Thus, '''external meaning of parts is not necessary for a model to forecast accurately'''. As I've stated before, I'll take clear internal parts over fuzzy external parts. --top * ''If the "internal parts" aren't defined, they're not "clear"; in fact they're much fuzzier than any "fuzzy external parts."'' * They are clear to me. I don't know why they are not clear to you. You seem to trip up on language-specific stuff, not problems with the tag model itself. * ''I'd hardly expect you to find your own model unclear. It's unclear to us because parts of your model are undefined and not mapped to the real world. I can't tell whether or not I have problems with the tag model itself, because I'm not sure I understand the tag model. It would help enormously if you'd complete TopsTagModel.'' * I don't know what you would consider "complete". I'd need a reference sample from some other issue in software to see what you have in mind. The PDF you gave is far too large and difficult to serve as an easy-to-digest model for typical programmers. And again, there is NO "real world". Programming languages are abstractions in the head. The closest thing is their input and output. That's what I measure, not actual implementation, which can change in theory without affecting I/O, and so is not a stable reference point. (Plus, it often has efficiency artifacts that are not necessary for other purposes.) If YOU want to model actual implementation, that's fine, but it's not my (main) goal. Knock yourself out. (As a reminder, I include source code of app as "input".) * ''"Complete" would be explaining the majority of type-related language behaviour in typical imperative programming languages, such that the model would effectively answer common questions that typical programmers are likely to ask about typical languages. Programming languages, by the way, are more than "abstractions in the head" -- they are runnable on real machines. But enough deviation: Please complete TopsTagModel.'' * If you mean explaining how typical dynamic languages behave ''overall'', that's not really the job of the tag model. That would take up too many pages and defeat the stated purpose and goals. Instead I give typical and common examples based on such languages for "type related" issues. How expressions are evaluated in general is outside of its scope. But if the programmer has the patience to isolate issues to single operators and simple tests similar to those in TypeTagDifferenceDiscussion, then the model and related tests should be strait-forward for typical programmers to apply to tease out common type-related behavior of a given language. Thus, if you want a "complete" model interpreter, I'm not going to build one. One would have to build a separate one for each and every language, which is asking too much. Common sense language-specific adaptation is thus required (based on tests and possibly the manual). * ''No, I wouldn't expect you to explain typical dynamic languages overall. Just explaining variables and values or expressions -- at least to the extent done at the top of TypeSystemCategoriesInImperativeLanguages -- would be reasonable. For a model intended to be simple and illustrative, particularly for programmers having difficulty with the conventional explanations, requiring that "typical programmers ... tease out common type-related behavior" sounds considerably more difficult (and error-prone, and frustrating) than simply providing an appropriately comprehensive and easy-to-use model. Indeed, if your intent is genuinely to help programmers experiencing difficulty with conventional explanations, wouldn't it make more sense to help them understand conventional explanations, rather than try to replace them with a whole new model? Wouldn't it be better to create an explanation of imperative (dynamic) programming language TypeSystem behaviour using familiar terminology and concepts -- but clarified and disambiguated -- that meets your standards of clarity, un-ambiguity, and un-fuzziness?'' * As I have repeatedly stated, the existing usage is fuzzy. If I could find a nice way to work existing terminology into the model without problems, I'd do it. So far I haven't, so avoid the problem with "types" by using a diff term. And it seems we both believe we have been clear with our descriptions yet dislike the other guy's description/writeup. I'm getting tired of playing "I'm not fuzzy, you are, no you are fuzzy, no, it's you who's fuzzy...". We are stuck at an impasse. I say let the reader choose the model that best fits their WetWare. * ''If the existing usage is fuzzy, un-fuzzify it. Explain it and clarify it. You add no clarity by merely replacing it and then not defining the replacement. You could, of course, add clarity by completing TopsTagModel. At least that would give the reader a fair shot at choosing the model that best fits their WetWare. As it stands, we don't have a definitive description of your model.'' * I cannot unfuzzy it without creating contradictions with existing usage. It's just too overloaded for me to fix. Or at least I'm not smart enough to fix that if a solution exists somewhere in the "math of the universe". Your dancing around the cfArgument "type" overlap issue is an example. As far as TopsTagModel, I'll leave comments about that under that topic. * ''What contradictions does attempting to unfuzzy it create? What do you mean by "dancing around the cfArgument "type" overlap issue" mean? It's been pointed out multiple times that "type" means the same thing everywhere it appears.'' * Your model doesn't reflect that in any clear way. Again, I want to model objective stuff, not head models. * ''Every use of "variable" means "variable", every use of "value" means "value", and every use of "tag" means (I assume) "tag". So why would every use of "type" be any different? It's not necessary to draw arrows between every use of the same word to indicate that it has the same meaning, especially in scientific and technical writing where unless otherwise stated, every use of the same word unquestionably means the same thing.'' * So you say. * ''"So you say" is a particularly ineffective counterargument. In fact, it makes it appear that you agree with me but aren't brave enough to admit it.'' * It's a repeat of prior claims that your pet materials are clear. Re-arguing that yet again repeatedly multiple times is likely of little use. * ''Incorrect. I'm not making any claims as to clarity or otherwise. My claim is that when a given term is used multiple times in scientific or technical writing, it's intended specifically to mean the same thing every time.'' * "Intended", perhaps, but they fail short of their goal. "Types" is a vague word. Attempts to define have either utterly failed, or have to be limited to a specific domain/language/model and are only clear within that specific model. * ''So it's fortunate that our model doesn't rely on a definition of "type" or "types", isn't it?'' * When YOU talk about "types", it sometimes doesn't jive with your model's use of it, the cfArgument example being one such case. * ''How does cfArgument not "jive" with our model's use of "types"?'' * Your model does not use the part called "type" in your XML representation to model the processing of cfArgument and it's "type" attribute. This makes it confusing to users. The part called "type" in your model has nothing to do with the part called "type" in cfArgument. Further, you say they are somehow all still the same concept, but your model doesn't demonstrate that. They are not the "same concept" ''in'' your model. -t * ''No, it's the same concept. In Category S languages, strings of characters are parsed during LexicalAnalysis to identify their type. In Category D1 languages, strings of characters are parsed during LexicalAnalysis to identify their type. In Category D2 languages, strings of characters can be parsed at run-time -- using cfArgument -- to identify (via a true/false response) their type. The fact that in all three language categories, strings of characters can be parsed at run-time to identify (via a true/false response) their type means the mention of cfArgument at the top of TypeSystemCategoriesInImperativeLanguages is unnecessary -- as it's not a distinguishing characteristic -- but it is notable as being a means by which explicit TypeChecking can be implemented in Category D2 languages.'' * Again, it's not the same in your model as described because your model does not use that part to explain cfArgument. That's a true statement. Being a "distinguishing characteristic" is irrelevant to name overloading. Also consider the fact that a D1 language could also posses something like cfArgument that also parses. Thus, being D1 or D2 is not the issue. (D1 languages often use a mixture of parsing and tag analysis, depending on operator etc.) * ''Yes, I did consider "the fact that a D1 language could also possess something like cfArgument that also parses". That's what I meant by "in all three language categories, strings of characters can be parsed at run-time". I'm not sure what you mean by "[my] model does not use that part to explain cfArgument." What part? The "type" part? It's not clear to me what you mean. Would it address your concerns if I removed all mention of cfArgument from the description at the top of TypeSystemCategoriesInImperativeLanguages? As it's not a distinguishing difference between S, D1 and D2 languages, maybe it should be omitted.'' * But you are not addressing the usage of "type" in your XML model of a variable, and the "type" attribute in cfArgument. You do not explain the connection between those two words. If you want a word-centric model, then it DOES matter, you can't just hand-wave them away because they stump you. If the connection is accidental or coincidental, then say so. Mentioning parsing by itself does not solve the word overlap problem. * ''"Type" is the same word, and therefore has the same meaning, wherever it appears. If it helps, imagine a line connecting all uses of "type" leading to an arrow pointing to a box with the label "type definition". Again, I'm happy to remove cfArgument if it bothers you; it's not essential, only illustrative.'' * You have not shown how it "has the same meaning". And a connecting line that has no empirical impact is of no known use and doesn't solve anything. Again, your model does not explain the connection between those words. * ''It doesn't have to. I haven't shown how "the" or "it" have the same meaning, either, because we can safely assume that in the absence of any explanation to the contrary, every use of word means precisely the same thing everywhere it appears. That's true even of my use of "variable" and "value". "Type" is used in the conventional fashion everywhere it appears. Once again, I'm happy to remove cfArgument if it bothers you; it's not essential, only illustrative. Would that help?'' * Sorry, you haven't demonstrated "type means precisely the same thing everywhere it appears". Nor have you clearly explained the connection in your model between "type" in your XML model and "type" in CFargument. It looks to me like waffling. * ''I haven't demonstrated that "variable" means the same thing everywhere it appears, nor have you. Why is that?'' * We are talking about types, not variables. (Actually we addressed variables already, but I won't repeat it here.) * ''Why should types be treated differently from variables?'' * I don't understand. We are discussing the nature of types, not the nature of variables here. Has it become a pivotal issue here and now? * ''You appear to require every reference to "type" to be explicitly related, but don't appear to require every reference "variable" to be explicitly related. Why require an explicit connection between every reference to "type", but not to "variable"?'' * It hasn't really been a point of contention/confusion yet, at least not to the level of "types". I wish to solve big problems before solving small problems. If a big issue begins to be heavily dependent on a small issue, then the small issue is probably worth an early visit. Otherwise, it's generally considered more rational to tackle big problems before small problems (unless the small problems are easily resolved). * ''So it's obvious that every reference to "variable" means the same thing. Otherwise, I presume my (and your) use of "variable" would be a "big issue". Why isn't it obvious that every reference to "type" means the same thing? Is it because you're intending to argue that Category D2 languages have no types and isn't TypeChecking?'' * Is the first sentence a claim? I'm not taking a stance on whether "variable" is clear or not at this point. It may make an interesting topic, but I'm not delving into that now. And I'm not attempting to define "types" either. I'm just describing ways to build language-specific models to match I/O. Whether we call the parts "variables", "types", or "bwaffsnobbles" is of secondary importance to matching I/O. * ''I'm not making a claim, only pointing out the apparent hypocrisy in demanding that all references to "type" be connected, but not making similar demands for "variable", "value", "is", "and", "that", and so on.'' * One patch to vagueness at a time. I see no reason to tackle everything at once. A 1D threadmess is better than 7D threadmess. It appears you wish to change the subject because you dug a verbal hole for yourself. * ''It's been the same subject all along and still is: Every use of "type" means precisely the same thing, just like every use of "variable" means the same thing. If you disagree, please show how at least one reference to "type" is not, in fact, a "type".'' * "Type" is vague, and in dynamic languages is often determined/defined by each specific operator. For example, getType() in Php uses different info from the variable than some of the is_typeX functions. What "type" means to getType is different than what "type" means to is_number() (if we can even use the word "means"). * There's no law of the universe that says a language must parse. It can go by the type tag only if it wants and never attempt a parse. And there's no law saying it MUST look at the tags. See #5. A language maker has a wide combination of choice as '''no Interpreter Police can stop them'''. I agree that tradition may actually limit existing language variations, but I'm ignoring that to have a more thorough perspective. -t * ''Yes, that's what this whole section describes. You did read below this point, yes?'' * I don't believe you've covered every possible implementation (rule set). If you have, congratulations, but implementation is not my primary goal here. -t * ''If there are missing ones, please let me know. Implementation is not my goal, either -- accurate, simple explanation is my goal here.'' * It's not clear from the notation when parsing (coercion?) occurs. * ''Look for the word "parsing" in my descriptions, or (in one case) "attempts to convert its operands to numeric values." For example, above, "the second and third parsing strings [as needed] to determine if they represent numeric values". In other words, the second and third operators parse their own string operands when they run. (In retrospect, "as needed" adds nothing. I'll remove it.)'' * It's not clear to me when this parsing happens or doesn't. Contrast language #2 and #6. I don't see how you account for such. * ''It's done explicitly by the operator itself. For example, an operator like +(string, integer) will probably be defined as something like:'' int plus(string p1, int p2) { int v1 = tryToConvertToIntegerAndThrowExceptionIfFailed(p1) int v2 = p2 return v1 + v2; } * That doesn't fit #2. If you recall, I asked you to contrast #2 and #6 a few sentences ago. * ''Sorry, I described where parsing occurs '''in general''' and hoped that would answer your question by implication. Your example #2 matches an operator with the signature "+(string, int) string" that implements concatenation, and it doesn't do any parsing -- it simply converts the operands values to strings, concatenates them, and returns the result.'' * Specifics are needed for "matches the signature". What are the EXACT rules for matchiness? * ''If a value is of type , it matches a signature parameter of type . This works independently of whether the language is Category D1, Category D2, or Category S from TypeSystemCategoriesInImperativeLanguages. In Category D2, for example, "+" has only one implementation (because values are always strings) and therefore only one signature, which is "+(string, string) returns string"'' * But how does one know that something "is type X"? * ''The language is implemented to identify "type X" based on what the language designer wants "type X" to be. Some approaches to this are canonical, such as identifying the sequence of characters "34" as a string and the sequence of characters 34 as an integer, but this is ultimately entirely up to the individual language. EsotericProgrammingLanguage''''''s often play with this to achieve amusing, obfuscating, and/or illustrative effect.'' * That's right: each language can do it differently. But for the illustration we can at least state our assumptions, such as quotes setting the type tag of a var or constant to "string". I've created a specific data structure (XML) to "hold" that setting (tag) in the model so that we don't have to use fuzzy language like "associated with". It's a visual representation of "tag", not a verbal one, which makes it clear that there is only one and only one tag per variable, something verbal modelling can't do very well. * ''What's vague about "associated with"? In "x is associated with y", it simply means that given x, we can answer questions about y. That's not vague, that's precise -- without implying anything about the mechanism of association.'' * As long as we know how to empirically test "associated with" and know how to tell if there are other associated-with's affecting things also or if there is a rule that limits associated-with's quantity and test how AW(s) affects results versus no AW. And how long AW lasts (scope). * ''Sorry, you've lost me. I understand the sentence (I think), but not how it relates to the above.'' * I'm telling you the kinds of things "associated with" doesn't answer by itself. * ''Why would you expect "associated with" to answer questions about scope any more than "has a tag" answers questions about scope?'' * It doesn't. That's why I added an XML representation to the model. I don't have to rely on ''just'' goddam English. Granted, you did so also for your model, but seem to ignore it for unspecified reasons in some cases. * ''Why would you expect an XML representation to answer questions about scope any more than "associated with" or "has a" answers questions about scope? My XML representation was merely intended to illustrate variables and values for those (i.e., you) who appeared unable to grasp my other diagrams and notations. Could you point out the cases where I "ignore it for unspecified reasons"?'' * The XML tells me: 1) It's "stored with" the variable (it's in the var's structure) so that it likely has the same scope and duration as the variable, 2) There is one and only one tag/type attribute because that's the rule of XML. Your other notation is a PrivateLanguage. I'll point out the "ignore" issue as I re-encounter it. * ''You appear to be using your own personal interpretations of XML to infer characteristics -- i.e., that the type reference has the same scope and duration as the variable -- that others would not necessarily infer from XML. Why, for example, couldn't the type attribute come and go independent of the variable? As for my other notation being a PrivateLanguage, it's not a PrivateLanguage because it's defined what it means. x ---> y is equivalent to "x is associated with y" which is equivalent to "given x, we can answer questions about y" which is equivalent to "x has a y". However, x ---> y is '''not''' the same as "stored with", because "stored with" implies an implementation structure that does not necessarily exist. It's also bizarre to call a type a "tag", and you've still not answered my question about what happens to your model if we replace "tag" with "float, boolean, date, integer, etc." Are you going to answer it?'' * It's "acts like it's stored with", not necessarily actual implementation. Remember, equivalency is allowed in the model as long as it matches I/O. If it came and went independently of the variable, then it would be best to use some kind of indirection in the representation, along with a statement concerning the semi-independence. Without such indirection, it's reasonable to assume they are born and die together (unless stated elsewhere). That's normally how XML is used: you don't jam independent stuff into the same XML tag or tag group. * I don't know what you mean by "we can answer questions". I just see funny characters in your invented notation, not answers. Sure you can answer questions, but you don't. I don't understand your "float" question either. Why would one want to do such? It serves no purpose I can see. The value portion of the tag attribute structure is dependent on a specific language. This should be blatantly obvious, but for some odd reason it's not to you. * ''In your model, if you replace the word "tag" with the phrase "float, boolean, date, integer, etc.", does it change how your model works?'' * Yes! For one, it hard-wires the available types, which should be done on a language-specific basis. Second, it's verbose (even after reworking it to force fit it into a sentence.) It's a silly way document stuff. That's like saying, "knife, spoon, fork, pizza cutter, etc." instead of "silverware". * ''Yes, it is a silly way to document stuff, but work with me here. Note the "... etc.", which implies that we could include all similar things in the list. For example, we could include "long, double, real, etc." Right?'' * How about you address the "we can answer questions" question instead of tinker with words? * ''In the phrase "x is associated with y", it means given x we know y. If we know y, then we can answer questions about y. Therefore, if we know x, we can answer questions about y. For example, "variable x is associated with type 'int'". Question: what values does 'int' specify? Answer: integers. Question: what values is variable x limited to? Answer: integers. Now, back to the point at hand: (from above) Note the "... etc.", which implies that we could include all similar things in the list. For example, we could include "long, double, real, etc." Right?'' * Re: "Question: what values is variable x limited to? Answer: integers." Nope. The association statement does NOT limit it to one and only one "type". Associations by themselves do '''not cut off other associations'''. In fact, isX() kind of operators can answer "yes" to multiple "types" (including D1), seemingly contradicting typeName() like operators. * ''My description was an illustration of the meaning of "x is associated with y"; it was not intended to make a definitive and/or universal statement about variables and types nor would I -- such statements are always in a context. For example, in statically typed languages, the "association statement" -- e.g., "variable x is associated with type 'int'" -- does limit variables to one and only one type and the association statement is often explicit, e.g., "int x;" declares that variable x is limited to values of type "int" which are integers.'' * DynamicTypesAreQuantum * ''"Quantum" generally means the minimal unit or amount of a physical property, so I'm not sure what you mean and the description on the page doesn't help. Do you mean each type consists of a set of indivisible (per that type) values which you intend to call quanta? I suppose there may be something in it, though I don't see how it applies here or why it's limited to dynamic types. Furthermore, types in DynamicTyping aren't (typically) dynamic; the term refers to the fact that values of any type may be assigned to variables.'' * There's more to quantum physics than step-size issues. * ''What does quantum physics have to do with anything on this page?'' * ''Now, back to the original question from above. Note the "etc" in the phrase "float, boolean, date, integer, etc." It implies that we could include all similar things in the list. For example, we could include "long, double, real, etc." Right?'' * It is not a list. We could perhaps say it's an item constrained by a list, at least in typical dynamic languages. * ''Why are you avoiding the question?'' * You are asking me to replace apples with oranges. The results read awkward to me. I have no flippen idea what you are getting at. I can describe how the hypothetical model looks at and changes the XML reference structure, and that should be familiar to most developers. They don't have to care about vocab; they are just changing an XML structure like they do every day in a code editor (during the "hand" simulation). With your replacement, it's not clear what "thing" it's talking about; some odd list floating out in space doing nothing definable and not part of or hooked up to any thing. If you want to integrate into part of the XML model as an experiment, that's fine, but describe what to change in the XML. * ''I'm not asking you whether it's grammatical or not, I'm asking you if the meaning of your model changes if you replace "tag" with "float, boolean, date, integer, long, double, real, '''etc.'''" Does it?'' * Meaning? The model is not about "meaning". Anyhow, it appears it breaks its prediction ability, as I interpret the change. * ''Never mind meaning, does it change how your model works? If it breaks its prediction ability, how does it do so?'' * I honestly don't even know how to incorporate it. I have no fricken clue as to what you are trying to achieve. It's like going into the operating room and telling the surgeon: "Replace the patient's spleen with this here shoe". The surgeon doesn't know what extent of the spleen to cut away, nor if or what to hook the shoe to in the body. * ''It's simple: Find some text you've written about your tag model and copy and paste it into your wordprocessor. Find-and-replace "tag" with "float, boolean, integer, string etc." (I've elided some items to keep it short.) Grammatical awkwardness aside, does your model change?'' * I don't know. It just becomes weird words that have no clear meaning. I define the model here as a way to transform an XML representation of a variable. Your suggestion taken at face value would create invalid XML: BEFORE: ..............^^^^^^^^^^^^.............. AFTER: ..............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^.............. * ''Ignore the XML. What about the descriptions?'' * The most thorough descriptions involve transforming the XML representation. The other ones are more general (and make no sense to me with your blunt substitution). That's been my goal: to describe the model in terms of "mechanical" changes to a data structure representation that we can all agree on, or at least be familiar with. This is '''to avoid excess reliance on English'''. "Ignoring the XML" pushes us right back into English Soup. * ''We'll come back to the XML later. The accompanying text is what I want to look at now. What happens to them if you replace "tag" with "float, boolean, integer, string etc."?'' * I get gibberish. * ''Interesting. Could you provide an example?'' * Well, to use an IT analogy, one could replace "tag" with "Type ID", which is like a pointer or subscript index to the "current" type. If you stick the entire list in the same context (cell), then it changes the nature of the reference. The closest reworked fit I can think of is, "Type ID where the ID has to be one of the following: float, boolean, integer, etc.". * ''What happens if you replace "tag" in your descriptions, and in your XML, with "TypeID"?'' * Nothing significant. It just seems to me that "ID" is a bit too specific and implies some kind of look-up table. It may be a "type name". Either generally works for modelling since the programmer usually cannot see the "ID" itself. In tests, one can only see the name usually (as output), not internal ID's, such that it's simpler to model most languages via type name to prevent a mapping step. (We don't really care about efficiency and space for this modelling.) * ''So you could replace "tag" in your model descriptions and illustrations with "T''''''ypeName", and nothing would change?'' * It may cause confusion with functions/methods called "typeName" in some langs. "Type ID" would perhaps be a better choice. * ''So, you're saying you could use "Type ID" everywhere you use "Tag"?'' * I believe so. I haven't found a flaw with the idea so far, but then again, we could call it a zopmiff and the model would still do its job. The main concern is to not have the model user confuse it stuff outside of the model, which is a weakness of your model (if I understand it correctly). * ''Wouldn't "Type ID" be much more familiar to programmers -- and more likely to be recognised -- than "tag", given that it appears you use "tag" to mean "Type ID"? '' * That's an interesting question. Actually, somebody else suggested "tag" when I used to use "flag", saying tag a known word in the compiler/interpreter design world. Googling around, I got this: ** http://programmers.stackexchange.com/questions/125275/how-is-type-checked-in-a-dynamic-language-interpreter-compiler-such-as-javascri *** "Javascript interpreter carries tag bits with each value for type dispatch. Could you elaborate a bit on this? For example, what's the use of tag bits? Does a bit correspond to a type? – dalibocai Dec 14 '11 at 16:03" ** http://okmij.org/ftp/tagless-final/index.html#in-fin *** "The absence of type-tag mismatch errors is the central property of GADT. The absence of unbound variable reference errors is assured either by higher-order abstract syntax (Xi et al., POPL 2003) or de Bruijn indices and dependent types (Pasalic et al., ICFP 2002). This page has described the final tagless approach. Type-tag mismatch errors are..." ** http://okmij.org/ftp/tagless-final/course/lecture.pdf *** "The most noticeable advantages of the final approach are seen in the encoding of typed object languages. The final approach expresses object language types as metalanguage types, without any type tagging and its accompanying overhead..." * ''The "somebody else" was me. I was the one who suggested "tag" when you used "flag", because in the discussions at the time -- which delved into implementation details -- "tag" was more representative of implementation reality than "flag". However, "type tags", "tag bits" and the like are implementation-specific mechanisms. Using the term "tag" to represent "type" (or "type ID") is like saying "V8" when you mean "engine". Yes, a "V8" '''is''' a specific type of engine, but it wouldn't be appropriate (and it would be confusing) to use "V8" when you mean "engine".'' ** Mirroring or resembling actual implementation to some extent is not a reason by itself to reject the term. "Sailors" don't use sails anymore, but the concept remains in derivations. ** ''But sailors don't use "sails" as a universal term to refer to motive power on boats; such usage would be misleading and potentially confusing. Similarly, the term "tag" conflates implementation with model in a manner that suggests the former and does nothing to clarity the latter.'' ** There are trade-offs to using cliches and analogies. Familiarity is sometimes valued over technical accuracy. A GUI "button" is not really a button, but a picture of a button. But we still call them "buttons" for familiarity reasons and brevity. UsefulLie. ** ''You're still using a term -- "tag" -- that invites more confusion than clarity, especially as "type" -- even undefined, misunderstood, or (and I'm not saying it is) overloaded -- is familiar and generally recognised.'' * In that case, let's call it "snizplep". No vocab overloading risk. Settled! * ''That's an excellent idea! Could you go through all the pages describing your snizplep model and replace every instance of "tag" with "snizplep"? That should make it as clear as possible, with no risk of confusing "tag" with HTML/XML tags and suchlike. If you like, I'll save you the effort and do the search-'n'-replace for you. Any objections? '' * "Tag" is shorter. * ''Then let's call it "zot". "Zot" doesn't risk confusion with HTML/XML tags, nor does it conflate a particular implementation mechanism with the general concept to which it refers.'' * {Well a tag may be a data definition, though I cannot be sure of that from what I am reading, so call it a "Datad". When we work out what it really means, it may become pervasive. It may be data adder, or data addressor, or data administrator, or data dictionary or ....} * ''I can state quite definitively that a tag -- as it's been used in the "tag model" -- is not a data definition. It is a type reference. For the sake of the "tag model", the best name mentioned so far is probably "type ID". See TypeSystemCategoriesInImperativeLanguages for the origins of this topic.'' ** {Cool - I get it now. It is a tag for each attribute, available and modifiable from inside or outside the process. The ID tag allows an attribute to be accessed in a manner appropriate, whether that is in the user interface, within a process, or as saved data in the database. Is that far from an understanding?} *** Um, no. What statements produced that interpretation? And what do you mean by "each attribute"? "ID" is perhaps not such a good name if it triggers all those associations. *** {What an edifying retort. I may as well revert to lurking.} ** ''Sort of. When we say a variable (which is what I assume you mean by "attribute") is an integer or a value is a string, we mean the variable's type is integer or the value's type is string. In that context, our correspondent rejects use of the term "type" and uses the term "tag". He calls this shift in terminology a "tag model".'' ** Because "type" is an overloaded term. ** ''It doesn't appear to be. I have yet to see a document whose use of the term "type" deviates from common use. Can you identify a document, either here or elsewhere, where the use of "type" deviates significantly from the common notion that a "type" defines a set of values and associated operations?'' ** "Common use" is overloaded, as I've explained probably 4 times at least already. Why do I have to keep explaining this? "CFargument type=" is an example given of an overload. ** ''There's no overload at all. It's doing type checking. ColdFusion's is functionally equivalent to, and conceptually identical to, a parameter declaration in C/C++/C#/Java of "int blah".'' ** Comparing to staticly-typed languages is apples to oranges because they require explicit type declarations. ** ''And isn't an explicit type declaration? Whilst C/C++/C#/Java require explicit type declarations for function parameters, ColdFusion provides optional explicit type declarations for function parameters. The notion of "type" is the same on both cases. What differs is in how you can use "type" in the context of function definitions.'' ** cfArgument only ensures that a variable passes a numeric "parse test". That's all we can say about the pass/resulting var since CF lacks ways to test for the tag (such as a typeName()-like function). In tagged dynamic languages, there are two possible ways to "implement" parameters specified to "be" a given type: 1. They simply pass a parse test but their tag is not changed (typeName(x) could return "String" for "123", yet let it pass thru and still be "string" per typeName.), 2. The tag is changed to be "integer" (or "numeric") in the function after parsing. (In both cases, an error is thrown if there is no way to convert to a number.) Actually, there's a 3rd option: Don't allow the variable unless its tag is already a numeric type, but this is rare in practice, for it reduces dynamicness. ** ''If we ignore notions of "tag" and "tagged" and "untagged" and "parse test" -- which do nothing to explain language behaviour in this particular case -- it appears the behaviour of cfArgument is precisely the same as using explicit parameter type declarations in C/C++/C#/Java. "Type" means the same thing in both. The only difference is that TypeChecking in C/C++/C#/Java occurs at compile-time, whereas in ColdFusion it occurs at run-time. Use of the term "type" appears to be wholly consistent and not overloaded.'' ** Sorry, I believe you are still wrong. Please demonstrate using C. As a reminder, I'm going to ask how "equivalency" is being measured beyond notiony feelings. ** ''"void fn(int c) {}; fn("zot");" fails because fn is invoked with a character string but its parameter is declared to be type int. The following fails for precisely the same reason: '' ** ''Equivalency, in this case, is defined as "has precisely the same semantics."'' ** The semantics are not the same. In this particular instance above the result happens to be the same, but the string "123" would not fail the check in CF yet fail in C (i think, I don't have a C compiler handy). C carries more (or different) info per variable than CF. ** ''They are the same. In both cases, a statically-typed parameter declaration is used to perform TypeChecking on function arguments. The only difference is between ColdFusion's definition of its "numeric" type vs C's definition of its "int" type, and the fact -- which is mostly irrelevant -- that ColdFusion does such TypeChecking at run-time whilst C does it at compile-time.'' ** Sorry, they are not identical. ** ''Conceptually, they are. As noted above, the only difference lies in ColdFusion's definition of "numeric" vs C's definition of "int". The semantics -- that a statically-typed parameter declaration is used to perform TypeChecking on function arguments -- are identical in both cases.'' ** The constructs act different from each other if we feed them "123" instead of "zot", so why would you say they are "conceptually identical"? Besides, concepts are in the head, and each head is different. I want to make this about something objectively measurable, not people's heads. ** ''They behave differently only because the types are different. Otherwise, they do '''exactly''' the same thing: They both use a statically-typed parameter declaration to perform TypeChecking on function arguments. The fact that the type is different is immaterial. For example, a hypothetical differs in type from , but both statements do '''exactly''' the same thing, don't they? The only difference is what type of values are accepted.'' ** How are you defining "type"? More explicitly, how does one verify they are "different types"? Input "123" behaves different (output) in one language than another. It's the '''same input'''. Is "123" a different "type" in one of the languages versus the other? If so, how do we empirically verify? And "is-a" implies a hierarchy, which may be a mistake. ** ''I define "type" as a set of values and associated operations. What defines "different types" -- and, particularly, what sequences of characters can be recognised as representing values of certain (typically canonical) types -- is up to the language designer. In one language "123" might be recognised as floating point, in another it might be an integer, in a third it might only be a string. The language designer decides.'' ** If it's up to the language designer, then semantics may depend on the language designer, no? That's what appears to be the case here. Thus, I have no idea why you claim the semantics are the same. ** ''Of course, the language designer could have decided to make dim the lights and spin down the hard drive, but he/she didn't. What he or she did do is make use a statically-typed parameter declaration to perform TypeChecking on function arguments. If you disagree, what do you think does?'' *** Whatever it's doing, it's not the same thing C (or a comparable dynamic language) is doing. C doesn't parse there, or anything that resembles parsing. *** ''Why is it important whether it parses or not? C also parses character sequences in order to determine types, but it does so at compile-time during the LexicalAnalysis phase. Shouldn't compile-time vs run-time be irrelevant here? Furthermore, there are obviously much more significant differences between C and ColdFusion -- in terms of general language functionality and behaviour -- than where and when character sequences get parsed to determine their type. Why do you consider internal implementation-specific detail of how TypeChecking is performed to be significant, but apparently consider the fundamental semantic operation that they share -- use of a statically-typed parameter declaration to perform TypeChecking on function arguments -- to be irrelevant?'' *** You claimed they were "semantically identical", but appear to be back-tracking, agreeing it's language-specific. And any ''general'' similarity is "in the head". Interpreters just blindly follow instructions and have no notion of "purpose" etc. Interpreters are dumber than insects. You appear to be '''anthropomorphizing interpreters/compilers.''' In the tag model I instead focus on modelling/mirror I/O and don't get caught up in philosophical meanings of things and words because then you have to consider different head models from different personalities. *** ''They are semantically identical, so I'm not back-tracking. You appear to be conflating implementation details with semantics. In both cases, they are doing precisely the same thing: They both use a statically-typed parameter declaration to perform TypeChecking on function arguments. If you disagree, what do you think they are doing?'' *** And, Re: "Why do you consider internal implementation-specific detail of how TypeChecking is performed to be significant..." - I'm modeling I/O, not necessarily implementation. I've said this probably a dozens times at least and don't understand why I have to repeat. I'm tempted to cuss. If it happens to match actual internal implementation, that's a lucky bonus, but NOT a requirement of the model. *** ''Ok, so how would a hypothetical in ColdFusion differ semantically from void fn(string c) {} in C++?'' *** Semantics is in the head. Interpreters/compilers just blindly follow rules, they don't give a shit about human thought. In that particular case, I don't know of a test (parameter value) that would expose an output difference, unlike the last one. *** ''I don't know why you insist on claiming "semantics is in the head". Semantics is about what languages do. Since there is no test that would "expose an output difference" -- which I presume to be your way of agreeing that the semantics are the same, it must be the case that they both use a statically-typed parameter declaration to perform TypeChecking on function arguments. If you disagree, what do you think they are doing?'' *** Two programs producing the same output doesn't necessarily mean they are equivalent. "print('4');" and "print(2+2);" produce the same result, but most would agree they are not equivalent. And we've been over the word "do" already. You haven't defined it clearly enough so far. Note that I could call what CF is "doing" to be "parsed-based run-time parameter validation". The C version does not check at run-time. We could test this by reading a value from user input and passing it to the function. *** ''"Do" is what happens when a program runs. Why does it matter whether TypeChecking is "parsed-based" or not? It's still TypeChecking. Why does "run-time" matter? True, the C version does not perform type checking at run-time, but if it did, it wouldn't (by definition!) be a statically-typed language. Doesn't that mean you're actually saying that ColdFusion is dynamically typed and C is statically typed? If so, that does nothing to contradict the fact that in ColdFusion is using a statically-typed (that's the "type=" attribute) parameter declaration (that's the tag and 'name' attribute) to perform TypeChecking (i.e., it fails if the argument does not match the type specified in the "type=" attribute) on function arguments (which is why it's called ).'' *** The issue is not whether "type checking" took place, but whether both code samples are "semantically equivalent". ** Further, in dynamic languages, the operator tends to determine what a "type" is, not the value. Some ops look at the tag (if there is one), some parse. See DynamicTypesAreQuantum. ** ''I don't know what "the tag" means, but it's certainly true that operators can interpret values how they like. That's true in every language. For example, in C, I can write a function called isOdd(int v) that returns 'true' if an integer is odd. I can then write a function called printIfOdd(int v) that uses isOdd() to (say) halt the program if v is even so it only accepts odd integer values. In that case, the operator is determining what a type is, not the value.'' ** That contradicts "I define "type" as a set of values and associated operations." Or perhaps I'm no clear on what you mean by "associated". ** ''What part contradicts the definition of "type" as a set of values and associated operations?'' ** We've been over this already. Everything in the universe is potentially "associated" in some way. Without some objective way to measure associated-ness, it's just a fuzzy head notion that varies per head. Further, associations should affect the I/O of the model or probably be discarded since they may end up distracting the reader. If it serves a purpose, then demonstrate it serving a purpose in your model, else toss it. ** ''We've been over what "associated with" means: "x is associated with y" is shorthand for "given x, we know y" or "given x, we can answer questions about y". For example, "a variable is associated with a type" means that given a variable, we can answer questions about its type. That does '''not''' mean everything in the universe is potentially "associated" in some way. Given my cat's name, for example, you can't answer questions about tomorrow's weather because they are not associated. Now: What part of the above contradicts the definition of "type" as a set of values and associated operations? Remember, "associated" means "given a set of values, we can answer questions about its operations."'' ** But it leaves too many unanswered questions. I made a list of questions it does not answer by itself somewhere. You suggested that your English sufficiently answered all of those, but it did not and you were wrong. I'll see if I can find the list. ** ''I'd be interested to see the list, and where you allege I was wrong.'' ** See PageAnchor: Assoc02 in TypeSystemCategoriesInImperativeLanguagesTwo. ** ''I see the list but I don't see where, allegedly, I was wrong.'' * The "data definition" is a representation of a "reference". "Reference" is a high-level abstraction (largely "in the head"), and "data definition" is a mid-level abstraction. (Specific byte layouts etc. would be the low-level). Thus, they are not mutually exclusive. And again, I'd like to avoid the word "type", or at least de-emphasize it, because of the overloading with parsed-value-based "types". I can fairly safely use "tag" by itself in descriptions, but not "ID". "Tag" is also a nice visual metaphor in that it's "attached" to the variable in a spot we know where to find, yet is not the primary part. The shirt is visible to the public, but not the tag (normally), yet we know right where to look to find out what's on it. (New-fangled clothing often prints directions on the inside of shirts such that there is no little white square anymore. Thus, in 50 years the association may not make sense. But in 50 years, Ceylons will be doing all the programming anyhow.) * ''What do you mean by "[t]he 'data definition' is a representation of a 'reference'" and "'[r]eference' is a high-level abstraction ... and 'data definition' is a mid-level abstraction"? A reference generally means a pointer or a unique identifier. What it points to or identifies could be a "data definition", and that generally means a concrete specification of data elements. For example, a 'struct' in C may be considered a "data definition", but it's a rather archaic term. It's been largely superseded by more specific terminology. I get your "tag" metaphor, but it's meaningless without some indication as to what's printed on the tag, and why. That's fully implied by "type"; completely evaded with "tag".'' * Sorry, you lost me. "Concrete" values of the tag (the set of all possible "type ID's") depend on the specific language being modeled and are obtained by reading the manual, observation, and hopefully experimentation. Same with your model. There are gazillion ways to model/emulate an interpreter for a given language, and for our purposes they are ALL "correct" if they predict I/O accurately within an acceptable time. On can use C struc's, gerbils, Legos, paramecium, and horses. * ''Without some indication of what a "tag" is, it's not clear what connection it has to the real world, and I thought your model didn't rely on "reading the manual." We don't use the term "tag" in discussing TypeSystem behaviour in popular imperative programming languages, so its use is confusing. What does emulating an interpreter have to do with this?'' * ''Now, what do you mean by "[t]he 'data definition' is a representation of a 'reference'" and "'[r]eference' is a high-level abstraction ... and 'data definition' is a mid-level abstraction"?'' * Not the "real world" debate yet again. Sigh. Again, how do we measure "connection to the real world"? If you say your ass is more "real world" than my ass, how do we objectively measure that? Is there a machine we can put our asses into and get a reading on dial? (TSA?) * ''It's rather crucial for elements of a model to match parts of the real world they model. Otherwise, it's not a model.'' * "Reference" is an abstract fuzzy head notion. "Data structure" is a notational or binary convention to "encode" or solidify that abstraction in a way that readers can relate to and use. I'm sure people spoke of "adding" before written math was invented, but the notation of math made it easier to share such common notions. But remember, TheMapIsNotTheTerritory; there are many different ways to encode "adding" and math in general. * ''There's nothing "abstract fuzzy head notion" about a reference. In Java, for example, "String p = new String()" means p is a reference to a String, which means it exhibits certain predictable and consistent behaviour. How is that an "abstract fuzzy head notion".'' * And I'm not against reading the manual, only saying it should not replace direct experimentation. * Re: "We don't use the term "tag" in discussing TypeSystem behavior in popular imperative programming languages." -- Sometimes it takes an asshole to wake people up from worn-out traditions that don't work well at communicating. I have to be that asshole; the God of Clarity compels me. * ''How well are you doing in your quest to "wake people up", here?'' * For the sake of argument, let's assume it's going horribly and has killed 42 kittens. ------ I removed some of the text from #7 above. It didn't make sense to me; anthropomorphizing interpreters in a confusing way. Here's the original snippet: * ''If I moved all the stuff that made no sense to me, there would be a lot of movement. If you don't understand something as written, why do you not seek clarification? You may not be the only one who doesn't understand. Though I do agree that the changes you made to my original entry do confuse it a bit. The grammatically questionable and entirely redundant phrase you added "interpreting + as addition being that it has operators for concatenation" is an example. '' * In the future, it would help if you signed or marked your content. It's possible I mistook some of your content for mine, and inadvertently "fixed" it. -t "The language performs the operation on the operands interpreting "+" as addition being that it has operators for concatenation. In the example case, the result would be 68. Languages in this category take the view that if anything is passed to a process it is appropriate to the requirements of that process - i.e. there is no error. If there is in fact erroneous data then the process should fail gracefully. Concatenation is a different operation and would be something like..." -------- [under construction] Processing type determined by: T:(__) getType(), I:(__) is_numeric(), O: (__) other operand Error handling: E:(__) Error raised if not expected type or conversion to number fails, N:(__) A special character or "mode", such as Not-a-Number is generated if not the expected type or a conversion fails. S:(__) String is assumed if conversion to number fails Ex#|Opn|Det|Err ---|---|---|-------- 01 | A | ? | ? 01 | B | ? | ? ---|---|---|-------- 02 | A | ? | ? 02 | B | ? | ? ---|---|---|-------- 03 | A | ? | ? 03 | B | ? | ? ---|---|---|-------- 04 | A | ? | ? 04 | B | ? | ? ---|---|---|-------- 05 | A | ? | ? 05 | B | ? | ? ---|---|---|-------- 06 | A | ? | ? 06 | B | ? | ? ---|---|---|-------- 07 | A | ? | ? 07 | B | ? | ? ---|---|---|-------- 08 | A | ? | ? 08 | B | ? | ? This is to eventually somewhat resemble the grids as found in TypeHandlingGrid. ---- See TypeSystemCategoriesInImperativeLanguages, TypeTagDifferenceDiscussion ---- SeptemberThirteen