Moved from ArgumentsAgainstTypeIndicators.

I'm not sure how to interpret "given" and "explicitly" in the definition of ManifestTyping. The terminology floating around out there is often fuzzy or inconsistent or dependent on arbitrarily chosen pet typing models (actual implementations or mental). The subject of "types" has a vocabulary problem in general. I believe this is largely because there are different ways to "think about" types and none of them are objectively wrong and/or not wrong-enough to prevent people from having certain close-enough notions. (Notions don't have to be accurate or consistent to "define" words among the population. Actual usage defines words, even if the usage is somewhat "stupid" or "illogical".) Past attempts to establish clear-cut algorithms or formulas or rule-sets to define such unambiguously have failed miserably. Endless and recursive LaynesLaw "battles" typically ensue. Instead we get anti-scientific bullshit such as IfYouWereSmartEnoughYoudJustKnow (what "types" are). -t

''It's not a question of "smart enough", but "informed enough."  The "ManifestTyping" page is merely one source among many, and by no means the best of a large and diverse lot.  Read more about ComputerScience and SoftwareEngineering and SetTheory.  Types are not as ambiguous and ill-defined -- or even as complex -- as you think, but there isn't a "clear-cut algorithm or formula or rule-set" that will help at this point, any more than there's a "clear-cut algorithm or formula or rule-set" that will identify (say) a cat.''

* [No, you think that it is "well-defined" because there are so many books and people talking about the subject with the sound of authority.  But unless they're specifying the ObjectArchitecture, what they're saying doesn't mean a damn thing.  Because you could ''theoretically'' implement (or ''tag'' ;^) your types with a special "floating-point" bit, or "character string" bit, etc. to implement types.  Popular architectures use special floating-point instructions to indicate type -- otherwise you have no means in which to discern 32 or 64-bits of binary digits, and how to operate on those bits now, do you?   This is not "graduate-level" study, this is a ConfusedComputerScience.]

* ''What does ObjectArchitecture have to do with it, and why does its absence mean "what they're saying doesn't mean a damn thing"? If you've got one bit representing "floating-point" vs "character string" -- i.e., 0 vs 1 -- how do you use it to represent a new type like "date"? How do machine-level instructions "indicate type", and what does that have to do with 32 bits vs 64 bits?  Who said anything about "graduate-level" study?  Etc.  What's notable about the ConfusedComputerScience page is it clearly demonstrates that ComputerScience isn't confused, but people can be.''

* [No, you still don't get it.  Answer me this, [sub]genius:  how does the purely abstract realm of your type and object model relate to the purely concrete facts (registers, transistors, etc.) of the machine?  That is, where is the '''''exact''''' articulation point in which they (i.e. software v. hardware) interface?  Because if you can't specify ''that'', you don't have an ObjectArchitecture, you have damnable ambiguity and false consistency (which is why it "smells badly").]

* ''Keep in mind the distinction between target language and implementation language.  The former is the language we're creating, the latter is the language in which the target interpreter or compiler is written.  The target language need not reflect any aspect of the implementation language, and the implementation language need not reflect any aspect of what lies below it, whether underlying machine or another language.  All that's required is that the implementation language be sufficiently expressive to be able to implement the desired target language.  The choice of type model is arbitrary.  The choice of object model -- should you even choose to have one -- is arbitrary.  The only "articulation point" where the hardware and software meet might be in the machine code emitted by (for example) a C compiler.  The C compiler is used to create a Java compiler, which is used to create a Jython interpreter, which is used to create a custom scripting language.  That custom scripting language -- which exposes none of the distantly-underlying machine -- may be the implementation language of an even higher level target language.  The code generator of the C compiler -- which even the C programmer doesn't see -- may be the only connection between the "concrete facts" of the machine and the purely abstract software that runs on it.  Furthermore, the C compiler might be running on a virtual machine that exposes none of the physical machine (or even another virtual machine) upon which it runs.''

You are claiming "if you read enough, you'll just know" as if claimers of clarity have no obligation to write clear-cut rules or algorithms or formulas to detecting presence or absence of type-ness etc. I'm skeptical of somebody who claims they know something so very well that they can identify its presence or absence, but cannot precisely articulate the "rules" their brain follows to make such classification. I suppose it's possible for such to be the case, but it makes communication, analysis, and testing about detection methods nearly impossible. 

An analogy may be a skilled hunter being able to identify a wild animal hidden in the brush. It may be an admirable skill, but if they cannot articulate the process their eyes and mind go through to perform that feat, they can cannot document that skill for others to follow and test. Further, we have not verified that you are actually seeing such animals since you never do the equivalent of bringing them back to the tent to prove they exist and are edible; you could be making it up for all we know. It's essentially, "trust me because I am experienced and skilled at spotting X". Whether true or false, it's '''not usable information''' to readers (unless they are only looking for a consultant with a high opinion of themselves to hire). It's not testable. It's just a claim.

''I'm not claiming that "if you read enough, you'll just know."  I'm claiming that if you read enough, you'll know more than you know now.  Expecting a Wiki page to be a substitute for extensive, graduate-level study is unreasonable.  It's obvious when you lack experience in a technical or theoretical area, usually to an extent that we can't even begin to fix it with a few paragraphs.  Whatever the subject, you'd be far better off learning about it than arguing.  Even better, stick to what you know and don't pretend expertise in areas where you obviously lack it.''

It's possible to cite such books to put together a "logic trail" case. Example:

Book A: All Q's must belong to set X, Y, or Z as shown in the following proof...

Book B: Q's cannot be X per following proof...

Book C: Q's cannot be Z per following proof...

Using these books and citations, one can put together the fact that Q's must belong to set Y.

But past attempts from you for this kind of info failed because you interpreted vague passages the way you wanted to. As quoted, they were vague. They seem hesitant to make concrete statements for some reason. Maybe you are somehow triangulating or averaging all the textual vagueness in your mind to get a clear picture or statistically reliable summary, but this triangulation or averaging or textual statistical summary process is not made clear to the reader. It's a black box. It's undocumented fuzzy math at best, and unconsciousness bias at worse. A professional compiler writer even called you out on some of your vocabulary claims.

Further, somewhere you admitted it's up to specific language authors what they call types, variables, values, etc. They are not obligated to follow textbooks. If that's the case, then textbooks are not the canon you claim they are. You contradict yourself.

Why don't type-related books ever make clear, definitive statements, such as "manifest types must have property X and must not have property Y"? (Where X and Y are clearly defined). They are strangely waffly.

'''Calling the other guy "stupid" is a cop-out for making/finding/citing and processing clear-cut definitive statements about type-related objects.'''

''I can appreciate that your lack of experience in ComputerScience -- and particularly in writing compilers, since you mention that -- would lead you to believe there is vagueness where there isn't.  Often, students at the beginning of their journey into a complex subject find it similarly vague, fuzzy, etc., until they have learned not only the core subject, but its surrounding subjects.  The inevitable variation of terms, omitted obviousness, and vagaries of academic writing can make a rigorous subject appear fluffy and vague to outsiders.  The only solution is to study more and learn more.  Citing books in a simplistic manner is no substitute for reading them.''

''I have written interpreters and compilers for a living, and currently work with former professional compiler writers and people who teach about writing compilers.  We share a common language, which is the language I use here.  The "professional compiler writer" who apparently "called me out" was posting nonsense.  The only evidence that he was a "professional compiler writer" was his claim to be one.  He never mentioned the products he apparently developed, nor could I find any connection between his name and any compiler.  I suspect, therefore, that he was a "professional compiler writer" the same way RichardKulisz was a professional operating system designer.''

A professional compiler writer disagreed with your term claims.

''Yes, you wrote that already.  You appear not to be reading my replies.  As I pointed out above, the only evidence that my correspondent was a "professional compiler writer" was his claim.  I could find no connection between his name and any compiler.  However, you '''can''' find a connection between my name (DaveVoorhis) and a DBMS with a language implementation that compiles to its internal VM (the RelProject), so I do know what I'm talking about.  It was obvious that the "professional compiler writer" didn't.''

* Let's put the "other guy" stuff together under Page_Anchor other-compiler-writer

Anyhow, we are getting off-topic, into a definition battle here. What we call these "kind" of types is a side issue.

''What types are you talking about?''

Classifications such as "Manifest typing", etc.

''Start here: http://en.wikipedia.org/wiki/Manifest_typing''

Do quotes qualify as an "explicit type indicator"?

''Manifest typing refers to explicit declaration of variable, parameter and return types.  It does not refer to symbols used to represent literals.''

One cannot know that with certainty by reading the definition as given. Where is the sanctioned explicitrometer?

''Where is the what?  ManifestTyping is characterised by the appearance of type names in the code to explicitly determine the types of variable, parameter and return types.  You might find it helpful to read all of the links in the box on the right-hand side of http://en.wikipedia.org/wiki/Type_system''

And by the reinterpretation, it's not clear to me at all what manifest typing has to do with tags versus non-tags (non-indicators) in typical dynamic languages. It's poorly written. Some of you guys need a serious lesson on documentation.

''See, for example http://en.wikipedia.org/wiki/Dynamic_typing#DYNAMIC ''

''If you find the WikiPedia documentation to be unclear, please improve it.  Like WardsWiki, WikiPedia is a wiki and you can edit it.'' 

It's clearer now to me because somebody used "type tag" :-) Honestly, it wasn't me. Although some dynamic languages don't use them, at least in a detectable way. The article did use the word "generally", which implies it's not an absolute requirement of "dynamic typing". But that's part of the grand "type vocabulary" problem: nobody wants to commit to anything solid. It's either words like "generally", or FractalVagueness. -t

''"Type tag" is a legitimate implementation mechanism, but it's never been clear whether your use of the term accords with its recognised use.  Type tags -- or more accurately, explicit type references -- are often used, but not always.  For example, languages where all values are represented as strings require no explicit type references because the language implementation assumes all values are represented as type "string".  In other words, every value has an implicit reference to type "string".''

* We've been over this implementation versus "semantics" battle before. The problem is that so far the "semantics" are '''not scientifically testable''' as given: they are too tied up in vague English. TuringComplete implementation models are at least scientifically testable.

* ''Implementation models represent theory, but do not encompass it.  Therefore, they are limited tools for reasoning.''

* At least they objectively exist and can be objectively testable. The "theory" as given is either fuzzy or disconnected from reality, a WalledGarden or AssumeCanOpener.

* ''It surely seems so if you are unfamiliar with it, much as (say) computer programming seems fuzzy or disconnected from reality until you learn it.''

* You are unfamiliar with science and objectivity, hallucinogenically mistaking your pet head models for universal truths.

* ''What does that have to do with my point, and how is it anything but an AdhominemAttack?''

* You claim I don't get "computer science" and I claim you don't get the (general) scientific process. If the second is not related to your point, why is the first related? It's the pot calling the kettle black. (That's not a racial slur, is it?) I will agree that "you don't get X" claims are usually useless either way. But, sometimes I throw stupid strategies back at jerks to see how they feel, as a lesson.

* ''ComputerScience isn't biology.  We're not trying to uncover new knowledge, but simply document existing knowledge.  The problem you're trying to tackle isn't science, it's technical writing.  It doesn't need new models; at best, it needs new explanations for the existing ones.''

* I will agree that AT LEAST it needs better explanations. Whether that's sufficient, I'll withhold judgement until I see the explanation candidate(s).

* ''Here's a general one: TypeSystemCategoriesInImperativeLanguages.  Any language reference manual is a specific one.''

* See PageAnchor TSCIIL-critique

''Type terminology is not vague, but it can seem that way whilst you're still developing an understanding of it.  It's a big picture, not fully comprehended by reading isolated snippets.''

"You just don't comprehend" is a copout. Professional compiler writers obviously "comprehend" compilers, and one told you that you were full of it. Thus, if you wish to go with anecdotal comprehension claims, then you can die by the same sword.

* ''I'm not saying you can't comprehend.  I'm saying you need to read more.''

* Page_Anchor other-compiler-writer

* ''Once again, the so-called "professional compiler writer" provided no evidence of credentials other than his own claim that he was a compiler writer.  Why didn't he mention what compilers he's written?  Furthermore, his posts were not the rational descriptions of a seasoned professional, but instead were mostly nonsense -- a conflation of theory, implementation practice, and some personal issue with mathematicians into a bizarre pastiche of semi-incoherence.  His self-described approach to implementing a virtual machine suggested he was -- at best -- a beginner of limited experience.''

* Almost every criticism there could be equally applied to ''you''. At least he signed with a name, which gives him at least some credibility points above you by my reckoning. All else being equal, I'll lean toward the real-named signer in judging anecdotal evidence. (And a pseudo-named signer above a non-signer.)

* ''I "signed" on this page, the second time you mentioned the "professional compiler writer", and I mentioned a real compiler I've written along with it.  I also must have signed something on or near the page where the "professional compiler writer" wrote, because he emailed me later to continue discussions outside of wiki.''

* So one gives their name, but no product name, and the other gives their product name, but no name. Do you dispute the "other" compiler writer actually writes compilers? Have they said anything clearly "wrong" that keeps compilers from actually producing the correct results? (For that matter, have I?)

* ''I gave both my name, and my product, on this very page.''  

* ''Does the "other" compiler writer actually write compilers?  It appears he wrote an interpreter in the 1980s for dBaseII (not dBaseIII), at a time when clearly-defined concepts of types, values and variables were less explicit, and the simplicity of computer systems meant ad-hack development could produce useful results armed only with knowledge of the machine and no theoretical background.  I see no evidence that he wrote compilers.  He demonstrates no knowledge of compiler theory, even at a purely pragmatic level, and using symbol table lookups inside his virtual machine (as he mentioned on a page here) suggests a lack of understanding of the separation between language interpretation, compilation, and execution.  Do his interpreters produce correct results?  I'm sure they do -- it's not difficult.  Does that mean he uses terminology correctly?  Not necessarily.  Look at the terminological bodge-job that is the PHP manual for an obvious demonstration that the ability to create a language implementation does not mean a sound understanding of the theory, let along a consistent use of the field's terminology.''

* dBASE II was commercially tested by millions. REL is a toy open-source project with goofy syntax used by a handful of academics who are paranoid about "duplicate" rows from SQL.

* ''Yes, dBASE II was commercially tested by millions, but the "other compiler writer's" tool -- which, as far as I can tell, implemented (a subset of?) dBASE II primarily for reporting -- wasn't.  Going by the number of Rel downloads, I suspect it's been tested by a lot more people than the dBASE II implementation.  Anyway, how is your response relevant to issues of terminology?  Particularly, how is it anything but an attempt at an AdhominemAttack?''

* And the PHP mess is consistent with all dynamic-type-related documentation I've seen. It's a good thing they give examples and user comments, because the writing sucks eggs to Pluto and back.

* ''Indeed, the PHP documentation is a mess.  If you read more about types and ComputerScience, you'd be able to put PHP in context and understand it better.''

* I understand how PHP '''behaves''' perfectly fine (for the context of discussion). The issue is the words used to describe its behavior. I want to see it described in terms that are clear to EVERYBODY, not just somebody who's read a stack of academic papers. It's not quantum physics, Bub (although you'd be an excellent candidate to turn it into such). My goal is to fix the documentation of such so it either makes sense to regular programmers, or is at least concrete about what it is saying.

* ''Then fix the PHP documentation.  Write a(nother) PHP book or on-line tutorial.  Your beef is with PHP, "bub", not TypeSystems or TypeTheory.''

* I introduced the "tag model" for just that kind of thing. It uses imperative algorithms and XML so as to be familiar to the audience. We've been over and over this already. You bitched that the data structure was "wrong" for convoluted reasons.

* ''Your "tag model" has nothing to do with the PHP documentation, and it's more convoluted than PHP's own documentation, which despite it's failings -- like frequently conflating expressions, values and variables -- actually does a reasonable job of explaining isNumeric() and the like.''

* I take issue with all of those, rejecting your pet definition of "value" as canonical, per past long and winding "value" debates. And the Php manual does not distinguish between "numeric strings" and plain "numeric", at least not in that topic, and if it's defined elsewhere, it should hyper-link to it. The reader has no way to know the difference between the two. The test for "numeric string" given does not necessarily fail "numeric" types because it's not clear if the "consists of [characters]" test applies to numerics. If a reader uses a write ("echo") statement, the output of a "numeric" does indeed "consist of" the given characters.

* ''I don't think winding debates are needed here; just simple documentation to explain that strings can encode literals of various types.  E.g., 123 is a literal number, "piffle" is a literal string, "123" is a literal string that encodes a literal number.  PHP's is_number() returns true if it's passed a string that encodes a literal number.''

* You make it sound like it's all about quotes. If that's the case, make a quote-centric vocabulary and model with clear rules etc. "Quote Science". (There's more to it than quotes, but I'll withhold such issues for now.)

* ''How do I "make it sound like it's all about quotes"?  I haven't mentioned quotes.  It's about strings and literals.  You can have a  string that contains only digits, and a function called is_numeric() that returns true if passed a string of digits.''

* I'm not sure what you are saying there, it's poor writing. You say X is a literal number, but you don't say clearly ''why''. I shouldn't have to ask you to clarify since that was the original goal.  And type-related results and computation don't happen just on literals. Functions can return variables with type-related behavior associated with them, for example.  

* ''Functions don't return variables in any language that I know of, though some regard a mutable instance of a class as a variable.  Is that what you meant?  Or do you mean a function can return a reference to a variable?  Anyway, a string can encode literals of other types, whether the string is stored in a variable, returned by a function, passed as an argument, or is a string literal.  By the way, I'm talking specifically about is_numeric() and its cousins here, not about type-related computation in general.''

* I should have said, "functions can supply content to variables such that they don't have to get their content from just literals." There has been too much emphasis on literals above. Literals are a part of the type picture, but not the entirety of types.

* ''True, literals are not the entirety of types, but the discussion here started with mention of "is_numeric()".  In PHP, is_numeric(p) returns true if p is of numeric type, or if p is a string consisting of a numeric literal.  The former is trivial; the latter is more interesting -- hence the focus on literals here.''

As written in available and cited material, it is vague. One very rarely finds any definitive statements along the lines of "X must have property Y" or "X must not have property Y". There's nothing concrete that's testable or that can be unambiguously converted into a clear algorithm or formula or list of formal logic statements. I've never seen such a big pile of fuzz except in religion and the field of psychology, but at least psychology doesn't claim to be solid, admitting it's a nascent field and not making bold pronouncements unless reproducible statistics are available. Something is wrong with "types" in the industry. 

''If "something is wrong with 'types' in the industry", how do we wind up with working programming languages that implement types?  How do we wind up with C, C#, C++, Java, Python, Perl, PHP, Ruby, and Javascript?  How do we have Lisp, Haskell, O'Caml, Pascal, FORTH and Prolog?  I suspect the only thing "wrong with 'types'" is your own aggravation at not finding them as easy to comprehend as a cheap novel.  Sometimes, with complex material, it helps to read the same thing more than once.''

Because the parts work how we expect them to work. '''Labeling the parts is a different matter''': machines just do what they are told to do and don't decide to function or not function based on what different humans may call their parts. We've developed a vague "notiony" vocabulary around types that has proven "good enough" to get real work done, but is NOT good enough for rigorous analysis. Like I pointed out before, "country music" has fuzzy boundaries. However, people still find it a useful term and it's "good enough" in most cases. Thus, something can be BOTH fuzzy and be useful enough to get work done (communicate). -t

''The parts work how we expect them to work because they are systematic.  The formal study of such systematic environments is called TypeTheory.  Really, it isn't that difficult -- you just need to read more.''

* They are NOT systematic. I gave plenty examples of loosy-goosy usage in colloquial land.

* [What happens in "colloquial land" is not particularly relevant to what happens when one is being rigorous. After all, the defining characteristic of colloquial speech is that it's relaxed in its usage.]

* I thought you were claiming the fact that they work well enough IN PRACTICE shows they are "systematic". Please clarify the scope and audience of your claim.

* [It's not my claim, and you've got it reversed. They work well in practice because they are systematic, not they are systematic because they work well in practice. However, your objection was that the '''words''', when used colloquially, were "loosy-goosy". That objection is irrelevant for the reason I just mentioned.]

* They are '''NOT systematic'''. We have things like Php's "isBool" that only looks at the type tag (indicator), and "isNumeric" that sees if the value is parse-able as numeric even if the tag is not numeric. Different languages deal with (or lack) tags differently. Most programmers don't give it any deep thought and simply spot-fix issues when encountered or learn defensive programming to avoid having to consider the variances. If the industry had better (clearer) models and/or better vocabulary, then the documentation AND languages may improve in that area. -t

* [It's a marginally more complex system. It's still systematic.]

* Depends on how you define "systematic". I will agree that for scalars there are generally two common ways dynamic "types" are done, but existing documentation does not define and distinguish between them very well at all.

* [I'm not aware of any definition of "systematic" that wouldn't fit. Can you cite a definition that it doesn't fit?]

* Perhaps one can say they are "systemic" in behavior, to some extent, being limited to two common approaches (tag-based and parse-based), but not systematically documented. The typical observable behavior (IoProfile) between the two approaches is similar enough that often a developer has a hard to distinguishing them unless they do careful experiments.

* [I'll take that as a no. Anyway, as was already pointed out on SignaturesAndSoftPolymorphism, your IoProfile can't tell the difference between the two approaches, even if you could ever actually complete it.]

* "Systemic" is not clearly defined enough either way. Existing definitions create FractalVagueness on terms such as "orderly" and "methodical". And I don't see any failure of IoProfile there. I just see misunderstandings. 

* [FractalVagueness, as you've defined it, is an unavoidable property of every word in every natural language. As such, it has nothing to do with how clearly defined a word is. As far as the IoProfile failure, can you come up with an IoProfile that can't be implemented in both approaches?]

* How about that, we've come to the point of a LaynesLaw mess over the meaning of "clearly defined". My point is that dynamic-type-related documentation as currently found is crap. And I'm still not following on your IoProfile fuss. How about posting a code sample THERE.

* [Really? The only word whose definition I've been arguing over is "systematic". Anyway, if that was your point, then your point wasn't relevant to what you responded to. As for the IoProfile, where are you having problems? I won't know what sort of code sample to create unless I know where your misundertanding lies.]

* I was going to ask how you measure "clearly defined" (your words), but then realized the futility in doing such.

* I don't know what you meant by "your IoProfile can't tell the difference between the two approaches" statement. Difference in what? IoProfile doesn't detect model classifications, only equivalency of two ''implementation'' instances in terms of externally observable behavior.

** [The two approaches you mentioned, of course.]

** You mean IoProfile can't detect the difference between tagged languages and parse-based typing? Sure it can! I already gave examples in the past, I just don't remember where they are at the moment. (The most obvious difference is that parse-based typing can't have the equivalent of a get_type() function.)

** ''I presume by "parse-based typing", you mean what's called a Category D2 language on TypeSystemCategoriesInImperativeLanguages?  Let's assume get_type(p) -- in keeping with the ethos of a Category D2 language -- doesn't return the name of the type of parameter p (it would always return "string" in a Category D2 language), but returns the name of a type determined by '''parsing''' parameter p.  How, then, would your IoProfile detect the difference between Category D1 and Category D2 languages?''

** The comparison of results wouldn't match and thus they'd have different I/O profiles. If you play with some examples on paper you'll see. I'm not in a mood explain it more now. Hint: you'll discover that a get_type() function is pretty useless in tag-free (D2) languages.

** [I did, and any (partial) I/O profile I could make with one type of language, I could also make with the other. It's why I suspected that I/O profiles were unable to differentiate between them. Figuring out why it couldn't didn't take too much longer.]

** Try: $a=123;$b='123';write(get_type($a).','.get_type($b)); A D2 language couldn't tell the difference such that both references to get_type() will produce the same output, but can be different in D1 languages because the quoting in the assignments (literals) affects the type tag. And why did you use the word "partial"? I will agree that if your actual test sample is too small, you might not catch the differences. This is explained in IoProfile. But a theoretically thorough set of tests would. After all, real interpreters/compilers probably have bugs that nobody has discovered/reported yet. Thus, it's an approximation (UsefulLie) to say that "vendor A's C++ compiler compiles the same language as vendor B's C++ compiler". We would say, "as far as we know, they both are equivalent/interchangeable". That is, their ''known'' IoProfile is the same.

** ["Can be different in D1 languages"? So, if the outputs are the same, then you still don't know if the language was D1 or D2. Additionally, there could be a D2 language where the value "123" was stored in $a and the value "'123'" was stored in $b (there not being a need for quotes to indicate that something is a string). get_type() would then return "integer" if the string contained only digits and "string" otherwise. So, if the outputs are different, you still don't know if the language was D1 or D2. So what good was the IoProfile in telling us whether or not the language was D1 or D2? BTW, I said partial because the IoProfile is infinite in most languages. We can't build infinite tables by adding individual entries, so the IoProfile that we work with is necessarily incomplete.]

** Let me clarify "same". Typical D1-output: "number,string". D2-output: either "number,number" or "string,string", depending on how get_type() is defined. (The D2 languages I know don't have a scalar get_type equivalent, BTW. It serves no practical value and overlaps with isTypeX-kind of functions, which are essentially parse-testers and may overlap in answers such that something can "be" 3 types as the same time, for example.) As far as "embedding" the quotes, like I've said at least twice before, in that case the quotes would be serving as de-facto tag(s): they ''are'' "type indicators". And yes, IoProfile is never 100% perfect in practice. I know that already. But, it sucks less than the alternatives.

** [If a D2 language were to have a get_type function, it would almost certainly be based on the same sort of things as the isTypeX kind of functions. Not much point in having a constant get_type function. Note also that D1 languages can also allow for something to be multiple types. In fact, just about any D1 language that wishes to support OO will do so. Finally, you are now basically defining tags in terms of the IoProfile. In that case, it will certainly be the case that the IoProfile can differentiate between them. Of course, now I have no reason to care about that distinction. I still find the IoProfile completely useless.]

** isTypeX functions won't completely match typeName (get_type) functions. As far as "be multiple types", that may depend on how one defines "be". In colloquial-land, "can be interpreted as type X" and "is type X" are often used interchangeably (although that can be very confusing). Most "tagged" (D1) languages have one and only one primary "type" per scalar. And I am not defining "tags" here. Basically it's in '''issue of parsimony''': is it "easier" to model (explain/mirror/emulate) a given language '''as having''' single-chamber values/content or as having a double-chamber. With enough tricks, layers, and bloat, it may be possible to use one to model behavior as the other and vise versa, but that's just quibble-fodder. It's a free country and one can pick any model they want; I only make recommendations and so do you. Different people will weigh "easier" differently and I'm not going to be a prick and insult people for not favoring an alleged "proper canon". -t

** [Did I say that they would completely match? Also what happens in colloquial speech is completely irrelevant. The only "be" that matters in this case is the one defined by the type system of the language in question. Yes, we are well aware that you won't define "tag" in spite of its importance to your approach. It's one of the things that makes using your approach so difficult.]

** You seem to be saying the parts are defined by implementation. '''This is a mistake''' because languages are typically not defined by implementation in practice. Implementations can be and are swapped/changed without the programming language user really caring. We've been over this already.  As far as defining stuff, your model has a type indicator also that does not appear to be clearly defined. Thus, it looks like hypocrisy.

** [Why do you think I'm saying that? Does your statement about typical languages mean you think that C, C++, and Java are atypical programming languages since they are defined in terms of an (abstract) implementation? What about Perl, which, if I remember correctly, was defined in terms of an official (actual) implementation? Finally, can you demonstrate an actual problem with the definition of type indicator that isn't dependent on some person using terms informally around the water cooler?]

*** I don't understand the "water cooler" question. Please restate.

*** [Explain what is wrong with the definition of type indicator. The fact that people might use the word loosely when speaking colloquially does not count as a problem.]

*** You appear to be giving a model, not a definition. And I don't see the relationship between the first sentence and the second in this topic.

*** [The reason for the second second sentence is to make it clear that appealing to the vagueness of colloquial speech does not indicate a problem with the term when it is used in a more formal setting. In other words, doing what you did when you said "loosey-goosey" at the start of this thread. It's a form of EquivocationFallacy on your part. Anyway, why do you think the definition of "type indicator" appears to be "giving a model"?]

*** So we are even LaynesLaw-ing over the definition of "definition"; how fitting. Your description sets up a fictitious universe, "let foo be a ...". That's similar to "assume a spherical cow". Definitions typically describe properties and the absence of properties, not relationships to ''assumed'' parts. "Type indicators must have feature set X and must not have feature set Y" is a more typical pattern of a definition.

*** [I'm not arguing about the definition of "definition". Anyway, it appears you have dodged the question once again.]

*** I am not aware of any dodging on my part. Perhaps you wrote the question poorly.

*** [I suppose that's possible, but I doubt it. What could be clearer than "Explain what is wrong with the definition of type indicator."]

*** Like I said, it's probably not a definition. Was that complaint not clear? That's a legit reply, NOT a "dodge", nor a Ford.

*** [That doesn't explain what is wrong with it, so yes, it is a dodge. Why do you think it's not a definition?]

*** I don't know of any formal test to distinguish between a model and definition. It APPEARS to me to be a model, and not a definition. Without a clear-cut way to distinguish, I cannot give specifics; it feels like a model to me. Likewise, you have not "proven" it's a definition. You can ''claim'' it's a definition all you want, but claims are a dime-a-dozen on the web. Without your proof to back your claim, its current status/category is "unknown", or in a conjecture state. -t

*** [You could start by stating which definition of "model" and "definition" you are using. Follow that up with the properties of the definition of type indicator that you think fits the definition of "model". You should also include some property that keeps it from meeting the definition of "definition". I certainly won't consider a "gut feeling" on your part an actual problem.]

*** Like I already said, patterns similar "let x be a foo and y be a bar, then z is composed of x's with y's in the..." are usually models. To borrow from geometry, geometry first establishes a model: a series of base axioms or assumptions, and then adds definitions ''on top of'' that. The middle section of your(s?) writeup closely fits that pattern. However, your root model has not been vetted for being the canon model etc. The model has to have population acceptance to be the grounds for universal definitions.

*** [In mathematics, a model is not "a series of base axioms or assumptions". A model is a collection of functions that map the parts of a language to the appropriate objects and relations. More informally, a model is what determines which statements in a language are true and which are not. I find it unlikely that you are using that definition of model. Please supply the definitions of "model", "definition", and "type indicator" that you are using here. (And while you are at it, what is a "universal definition"?]

*** Models are about language? Where are you getting that? You made the claim about the nature of your write-up, YOU do the proof that it's a definition. And even if by chance it is ''a'' definition, that doesn't make it "the" definition; for definitions are a form of ArgumentByPopularity. I know you claim it matches "common semantics" of such languages, but you have not demonstrated that with any clarity.

*** [Go read about formal logic. In particular, read about model theory. About the claim, you were the one who said, "your model has a type indicator also that does not appear to be clearly defined."? And was that not the first mention of the subject here? All I've done is asked you to provide evidence for your claim. As usual, none appears to be forthcoming.]

*** I know what the goddam hell formal logic is, and YOU are not using it. And the default is NOT that your thing is "clearly defined" until shown otherwise. The default is that the condition is "unknown" or at least "unestablished". Let your ass be a variable, and let my meter-wide boot be a type indicator. If I jam my boot quickly up your ass, then your ass contains a type indicator and the variable "has" a type indicator. That's the sort of "definition" you made with your "let" shit. You define artificial data-structure-like objects and then the target terms in terms of these artificial data-structure-like objects just as I just defined them in terms of your ass and a boot.

**** ''If you have an evidence-based argument against the "'let' shit" (by which I presume you mean the semi-formal treatment at the bottom of TypeSystemCategoriesInImperativeLanguages) then please present it, but try to avoid AdhominemAttack''''''s and incoherent vulgarity.  Your emotional tirades contribute nothing to convincing anyone that you're right, and they make it appear that you lack effective counter-arguments.  In your argument, please include a clarification of what you mean by "artificial data-structure-like objects".  Do you mean the notation used to represent associations between values, variables and types?''

**** Yes, I mean stuff like "4. Let V be a value, defined as V = (S, T) such that S ∈ T [...] 5. Let R be a variable, defined as R = (V)." That's arbitrary, or at least one of multiple modelling/design approaches to such. Granted, we may have to settle on an arbitrary model for reader clarification. Your complaints about my writing style are noted.

**** ''It represents how popular imperative programming languages are built, and how they work, without conflating language categories or introducing redundancy or needless complexity.  For example, in TopsTagModelTwo it appears that dynamically-typed language variables have an explicit type (aka "type_tag") attribute, which runs contrary to how popular dynamically-typed languages work.  There is no popular dynamically-typed imperative programming language where a variable is ever perceived to have a type distinct from the type of the value most recently assigned to that variable, so why should a variable be complicated by having its own 'type' attribute?'' 

**** PageAnchor English-Fuzz-01

**** We've been round and round on these issues in something like 5 topic pages already. You appear to interpret certain English phrases far different than I do. I don't know how to resolve that, for I cannot X-ray how the English is being processed in your head. TopsTagModelTwo does ''not'' clearly contradict a majority of the written material as I interpret the English used to describe typical dynamic languages. Granted, the terms appear to be overloaded in colloquial usage, which suggests that multiple different models/definitions can still "fit". The biggest problem with the existing text is that it rarely has "negative" statements, such as "X must never have a Y inside of it" or the like. Without those negatives, it's difficult to test or rule out various overloaded or alternative interpretations of words or phrases. -t

***** ''I don't know whether TopsTagModelTwo contradicts language documentation or not, but it doesn't matter -- as you've pointed out, language documentation is often poor.  TopsTagModelTwo certainly contradicts the semantics of popular dynamically-typed imperative programming languages. In popular dynamically-typed imperative programming languages, can you think of an operation on a variable -- i.e., a variable's semantics -- other than "store a value" and "retrieve a value"?  In particular, is there a "store a type" or "retrieve the type" of a variable, independent of the value the variable contains?''

***** We've been over this already in the "value battle" topics. "Semantics" is not objectively observable in a way sufficient for cross-human analysis. I cannot bash people's heads open and dissect their neurons: that's illegal...and mean. "Semantics" is in the head. We can only analyze words or diagrams written about "semantics" at this point. And there are "retrieve the type" operations, such as Php's "getType()". The other is essentially type conversion. It can be done with code such as "trim($myNumber);" or Php's "casting" operations (which is awkward language design IMO, but that's another topic). And TopsTagModelTwo can "store a value". 

***** ''You appear to be conflating programming language semantics -- which are the elements of a language and the operations that can be performed on them -- with human interpretation of language semantics.  The latter may be interesting from (say) a pedagogical point of view, but are irrelevant here.  Please answer my original question:  Is there a "store a type" or "retrieve the type" of a variable, independent of the value the variable contains, in any popular imperative dynamically-typed programming language?  As for getType(), getType(p) works whether p is a single variable or a complex expression.  What does this tell us?''

****** It tells us that both variables and expressions can (somehow) produce a type indicator. And you'll have to clearly define/describe what the "X a type" operations do in order for me to give a solid answer. I already answered them as I can best interpret your words so far. As far as "conflating semantics", we've been around and around on the meaning of semantics already. You have not shown an objective and useful way to measure and compare semantics in order to verify claims made about semantics. Claims are cheap; we need solid evidence.

****** ''In programming languages, semantics and syntax are all there is.  Comparing and "measuring" semantics is a straightforward discussion of language elements and the operations on them.  In particular, the semantics of variables are simply that values can be assigned to variables and retrieved from them.  This is common knowledge, part of the ComputerScience and SoftwareEngineering canon, taught in every programmer's first lessons on programming and reinforced by every programmer's first lessons on computer architecture and ComputerScience.  It's a direct result of VonNeumann architecture: memory addresses (variables) contain values.  No one is taught -- in DynamicallyTyped languages, at least -- that variables are assigned types or that types are retrieved from variables, but everyone is taught that values belong to types like integer, character, float, and so on.  This is canonical knowledge, and it is so ubiquitous and fundamental that it hardly bears mentioning outside of the beginner's classes where it's taught.''

****** El Wrongo. You appear to be mistaking your personal head models for universal truths. The existing writing on dynamic types as written does NOT clearly triangulate to your claimed canon. (Some passages may lean a certain way, others won't.) If you want to present a carefully dissected and documented textual analysis (literature analysis) be my guest, but at this point you only have ArgumentFromAuthority. And we are talking about high-level languages, not assembler. Further, assembler conventions lean closer to compiled languages (which can reliably "discard" a lot of type-related info during run-time because execution paths have been pre-vetted.) Extrapolating assembler concepts into dynamic languages is not a good idea.

****** ''We've already agreed that "existing writing on dynamic types" -- or at least existing documentation for DynamicallyTyped languages -- tends to be rather dire, so whether it "triangulate[s] to [my] claimed canon" or not is irrelevant.  What's important is that the fundamentals of ComputerScience and computer architecture -- particularly that memory addresses (variables) contain values, and that each value's representation (i.e., what a memory address stores) must be associated with a type in order to be meaningfully manipulated (which is dictated by logic, not documentation) -- are consistent with my descriptions.''

****** Apparently you have a very unusual way of interpreting the phrase "associated with" that differs much from my interpretation. I don't want to do English battles with your odd little mind yet again over that phrase. Neither side is going to change how the other reads and interprets English. Maybe your UK background has something to do with it in that it differs from my west-coast American exposure to English.

****** ''What do you consider unusual about my interpretation of the phrase "associated with"?  As for my "UK background", I was raised in North America and spent a significant proportion of my professional career there, so if anything, my interpretation of English is likely to be broader and more general than yours.'' 

****** In my model, the type '''is clearly''' associated with the value as I interpret the phrase "associated with". But you say it's not for reasons that escape me.

****** ''I don't recall saying that types are not associated with values in your model, though it appears your model doesn't maintain an immutable pairing between a value representation and its corresponding type.  I.e., it appears that a given value can have its type changed independently of its value representation.  For example, your ''func updateTypeTag(vname: string, typeName: string)'' apparently changes the type of a variable independently of its value representation.  Why?''

****** I put a reply at the bottom of TopsTagModelTwo. 

***** ''In general, it appears your approach at TopsTagModelTwo is to say that EverythingIsa variable -- or can be represented by the "variable" construct -- but some variables are immutable and have blank names.  However, in the descriptions at TypeSystemCategoriesInImperativeLanguages, what you treat as different kinds of "variables" are defined as distinct constructs -- variables and values -- and "value" is used wherever that construct is both immutable and anonymous.  Your approach is sometimes appropriate to implementations -- there may be valid technical reasons for using the same implementation structure for a variety of purposes -- so leaving some of its attributes blank is acceptable.  For an abstract model -- which is what TypeSystemCategoriesInImperativeLanguages describes -- it is not acceptable.  If modelling suggests a construct with an attribute that is sometimes not set and not used, but other times set and used, it should be two distinct constructs -- one with the attribute and one without.  It's simpler that way, because we don't (for example) have to model blank attributes, or model testing for attributes being set or not.''

****** We've been over these "design tradeoffs" and your anti-empty/null-attribute stances before. We will probably never agree, for we seem to be using different assumptions about WetWare. Machines don't care either way: they just blindly follow rules, only human minds care about designs, and different minds prefer different designs and measure parsimony differently. See also NoTypeCanon. I'll LetTheReaderDecide rather than bicker up another 5 pages on that with you. -t

****** ''If your model defines attributes that can be null or not, then your model must test whether they are null or not.  That is inherently more complex than a model that neither requires a special "null" state nor must test whether an attribute holds that state.''

****** Your value model appears to face similar problems when dealing with nulls, just at different points of the process. It's WaterbedTheory. (I'm not fond of the way that many existing languages deal with nulls, but realize we are stuck with the current approach for the medium term.)

****** ''Can you show how my "value model appears to face similar problems dealing with nulls"?''

****** I don't feel like starting a null-related topic right now. The answer is "no". Maybe another day. You are probably going to argue that nulls "should be" implemented a certain way and I'll disagree, saying it's arbitrary or a personal design choice in terms of what trade-offs to balance against each other.

****** ''Nulls aren't required by TypeSystemCategoriesInImperativeLanguages, so there's no reason for me to argue how they should be implemented.  However, it appears that TopsTagModelTwo relies on nulls as part of the model itself.''

****** Can you show me where?

****** ''My mistake.  I recall that at some point you defined "variable" structures that could sometimes have a name and sometimes not, i.e., the 'name' attribute could be null.  It appears your "variable" structure always has a name.  Of course, that's further confirmation that TopsTagModelTwo is the run-time core of an interpreter rather than a model.  There is no such thing as (e.g.) a function return value with a name in any popular imperative programming language, so your TopsTagModelTwo isn't modelling the reality of popular imperative programming languages.''

****** By that logic an orrery that uses gears is not a "model" because real planets are not connected to wires and gears. '''Models are "allowed" to have internal parts'''. I would point out that when one is evaluating expressions on paper in grade school, it would not be uncommon to say something like "your intermediate result on the 4th line in the left margin has a mistake". Usually one just points to or circles it in practice which is easier than describing its page position with words, but I cannot practically model a finger so I give it a reference name instead. Think of the internal name as a shortcut for stuff like "your intermediate result on the 4th line in the left margin [of the page]".  -t

****** ''An orrery is a (vaguely) physical model, but it is certainly not a mathematical model.  Isn't TopsTagModelTwo intended to be a mathematical model of TypeSystems in popular imperative programming languages?  As such, it should be an abstraction of actual program language semantics -- without artifice, addition or omission.  However, if TopsTagModelTwo is a physical model, that's further confirmation of my view that it is a run-time engine designed to produce the same results as popular dynamically-typed imperative programming languages, but it does not offer an abstract mathematical model of them.''

****** Where did you get the idea that it was intended to be and/or should be a mathematical (only) abstraction? The goal is to make a "prediction tool". It may use math, Tinkertoys, and/or gerbils etc. to achieve that goal, depending on various design tradeoffs. If you want to make something for a different goal, that's fine.

****** ''In ComputerScience, models are invariably mathematical -- e.g., the RelationalModel -- so it's reasonable to assume that your goal is to create a mathematical model.  In ComputerScience, what you call a "model" is typically called an implementation, or perhaps an emulator or simulation if it's intended to resemble some real-world process.''

****** You seem to be out of the blue making up a rule such as, "All interpreter/compiler concepts must be described in formal math" (even in non-academic manuals). Hogwash!

****** ''I'm not making a rule, but simply stating standard practice in ComputerScience.  If you're going to call your TypeSystem emulator a "model", then you may wish to make it clear that it's not a model of TypeSystems, but a TypeSystem implementation intended to resemble that used some imperative programming languages.''

****** Bull on both "standard practice" and your misinterpretation of the term "model". Stop making things up; it's really annoying. If they are standard knowledge then link & cite, because I don't trust your claims at face value due to your trait of mistaking personal head models and assumptions for universal truths. Note that I use "model" in the colloquial/general sense of '''a device that mirrors target behavior of another device/system'''. "Model" may also mean something formal and specific in mathematics, but that is not my word usage domain here.

****** [For the situation in question, the definition of "model" is the same one that is used in mathematics. The fact that you aren't using that definition is what he wants you to be clear about.]

****** No. I'm using the general colloquial meaning. This is an IT wiki, not a math wiki.

****** [In that portion of IT (or Computer science if you prefer), the term "model" is usually the math one. You may use the more colloguail meaning, but to avoid confusion, you should say that you're using it.]

****** What is the first "that" referring to? And yes, I am using the colloquial version. Now let's move on.

****** [The portion of IT we are talking about. Namely, the portion that studies TypeSystem''''''s.]

****** I'm talking about making language manuals approachable to rank-and-file developers, not academic studies.

***** ''I suspect much of the argument here and on the ValueExistenceProof* topics is over the perception of the roles of TopsTagModelTwo vs TypeSystemCategoriesInImperativeLanguages.  The debates have assumed that they have the same role, so they're in competition, and therefore their differences represent vital distinctions that must be resolved.  But they're not in competition, because they don't have the same role.  TopsTagModelTwo is (mainly) pseudo-code for a generic dynamically-typed interpreter run-time core.  As such, it is '''not''' a model.  It does not generally describe or model relationships between values, variables and types in programming languages; it is intended to implement the value, variable, and type-related semantics of popular dynamically-typed imperative programming languages.  On the other hand, TypeSystemCategoriesInImperativeLanguages '''is''' a model of the relationship between values, variables and types in popular imperative programming languages.  Whilst the two documents inevitably overlap -- they're both talking about the same domain(s) -- they are fundamentally different in purpose and coverage and (hence) approach.  Therefore, I'm not sure there's any point in debating them further.  I still have issues with TopsTagModelTwo, but it doesn't really matter; when regarded as describing a run-time core rather than a model, my complaints become minor issues about a language implementation rather than major conceptual concerns about a model.''

***** The boundary between "model" and "implementation" is probably fuzzy. Possibly related in terms of a general description of types versus a specific description: NoTypeCanon. But I do believe your model/design of "variable" and "value" is arbitrary and thus it is not a general model of dynamic types in AlgolFamily languages; at least not the most general. The other professional interpreter/compiler writer also disagreed with you.

***** ''A valid model must consistently represent or reflect general reality, but an implementation may deviate from generality in order to produce desired local results.  Can you demonstrate any popular imperative programming language that does not adhere to my model of "variable" and "value"?  Can you show evidence that the "other professional interpreter/compiler writer"'s use of terminology is correct, and mine is incorrect?''

***** Like I have said many times, existing writing does not falsify EITHER model in a clear way. You should have anticipated that response and addressed it automatically. The fact that you didn't suggests you don't listen, discarding memories of replies you don't like. This seems to be a bias pattern of your personality in general. As far as the other compiler writer's opinion, I have no reason to value one opinion over the other, except that I know from experience that you tend to '''fixate''' on very narrow issues and edge cases, and complicate other issues to "solve" such spot-obsessions. Thus, I have to discount you some in comparison. Other readers can judge as they want. -t

***** ''I have perfect memory of your replies; I simply discount those that are invalid.  Whilst it is conceivable that your model -- when used to create a simulation of popular dynamically-typed language behaviour -- does generate equivalent results, that does not mean it is the most parsimonious or the most consistent with general understanding of language behaviour.  For example, can you demonstrate an example of a popular, dynamically-typed language where variables have types?  And by this, I don't mean the ''documentation'' of said languages; I'm referring to their semantics.''

***** We've been round and round on "have" already. You interpret such words so very much differently than I do when applying them to IT objects that I doubt we will ever see eye-to-eye. You process English in your mind too different from mine that we cannot seem to find common reference points. You claim your viewpoint comes from "common semantics", but don't show the details of the thought trail from that source to your interpretation of English.

***** ''Assume the statement 'p = 3;' exists in a popular imperative dynamically-typed programming language.  Would you say it means "assign 3 to p"?  Imagine variable p subsequently appears in an expression like "p + 2"; would you say it means "add p to 2"?''

***** Yes, "assign 3 to p" is a common way to describe such in colloquial programming discussions. However, I don't claim it has any precise meaning, at least not determinable in an objective way. I don't understand the last question. The most common description of such expression would be something like, "add p and 2 together, giving an intermediate result". Your use of "to" is awkward as we are not "changing" either operand. In math, the operands of a function are generally considered "read only" ("+" is essentially equivalent to a function here), which contradicts to-ness directed at either one, per how I process such words in my head.

***** ''These are colloquial discussions, so precise meaning is neither expected nor required.  As for "p + 2", describing it as "add p and 2 together, giving an intermediate result" is fine -- again, these are informal discussions.  Now, what single phrase would describe what we're doing just to 'p' in phrases like "assign 3 to p" or "assign 6 to p" or "assign 'zot' to p"?  What common phrase would describe we're doing just with 'p' in expressions like "p + 2" or "add p and 2 together, giving an intermediate result", or "3 * p" or "writeln(p)"?''

***** I'm not understanding your question. We are not "doing" anything with "p" other than "reading" it. Perhaps lay out your question as an example of two programmers communicating about some practical issue.

***** ''Ok.  Programmer 1: In line 13, it says "x = 3;" and in line 17, it says "y = 'foo'".  What is happening to x and y?  Programmer 1: In line 28, it says "p + 2" and in line 29, it says "writeln(p)".  What is happening with p?'' 

***** Arrrg. The ''specific'' context of the problem they are trying to solve/communicate is still missing. I'm NOT assuming two programmers are laying under the stars, smoking weed, and existentially philosophizing about variables in general. That's NOT the majority of the colloquial settings I encounter. The specific context matters. For example, programmer 1 may say, "I expect 'p' to have a 3 in it because of (such-and-such), but it has a 7. How did 7 get in?"

***** ''Ok.  The "''specific'' context of the problem" is that Programmer 1 and Programmer 2 are trying to understand the code -- maybe they're going to re-write it in another language, or fix a bug somewhere -- and are reading it in order to understand it.''

***** Still not specific enough. Invent a specific scenario in a specific application that does something specific. "What is happening with p" is too open ended. The answer would likely depend on the details of the case. 

***** ''Ok.  The specific scenario is that Programmer 1 has written the program, and wishes to explain it to Programmer 2 so that she can port it to a different language.  How would Programmer 1 explain line 13's, "x = 3;", line 17's "y = 'foo';", line 28's "p + 2", and line 29's "writeln(p)"?''

***** You lost me. Is #1 verbally reading code to #2? Why would he/she do that? That's not typical. Is #2 blind?

***** [#2 may or may not be blind. What we do know is that #2 doesn't understand what the code is doing. #1 is trying to help #2 understand.]

***** You are not talking about training newbies, I hope. I'm sorry, but as given, your scenario is still too nebulous for me to comment on how typical developers would communicate on various '''situational''' issues. Invent a realistic application scenario and a realistic problem being communicated about and describe both of these in careful clear full detail and we MIGHT get somewhere. The domain context often matters in knowing what is being asked.

***** ''What's wrong with training newbies?  Just read the code.  Assume it's Python, Perl, PHP, Ruby, C#, C, C++ or Java.  What do "x = 3;", "y = 'foo';", "p + 2", and "writeln(p)" do?'' 

***** I was assuming regular developers, not newbies. Your question was "What common phrase would describe we're doing just with 'p' in...". "Common" suggests we are not talking about newbies. Further, most language manuals are targeted at existing production programmers, not programming newbies. And somewhere we already did a LaynesLaw dance over the word "do" in this kind of context. I don't want to repeat that again. It's too vague and/or overloaded a word to use when exactness is desired. Going back to the original questions, let's see if we can work with my original answer that we are only "reading p" and otherwise not doing anything with it. Can you move forward with that?

***** ''Ok, let's use "reading p" to describe what happens in "p + 2" and "writeln(p)".  Would you agree, then, that "x = 3;" and "y = 'foo';" are "writing x" or "writing y", respectively?''

***** "Writing" usually refers to I/O in practice (such as to files or screen). Thus, I would not agree. With "x = 3;", as an example, colloquially it would be common to say it's "changing x".

***** ''That's fine.  Now, when we're "reading p", what is it that we are reading from p?''

***** Arrrrrg. We've been over this kind of thing multiple times. Again again, '''different developers will give different answers'''.  Some will say "contents", some will say "value", some will say "value and type", some view value and type rolled together like you do, some view them as separate "things", some mix and match such views depending on language or context, and a good many will say, "I don't know, that's detail of the compiler/interpreter that I cannot see; why the hell are you asking anyhow?". There is no objectively identifiable "solid" canonical model of the "guts" of variables/values/types in the '''heads of typical developers'''. I'm just the messenger. -t

***** ''Yes, different developers will give different answers; that's fine.  The relevant question -- for this threadlet, at least -- is this:  Can you think of a case, when "changing p" in any popular imperative DynamicallyTyped programming language, where we can change the type of 'p' without changing its value?''

***** We've been over this already. It depends how one measures "change" and defines/models/measures "type" and "value". Type casting and casting-like operations appear to sometimes change type without changing value under certain viewpoints/models of such items. You'll get different answers for that also.

***** ''Can you show me an example of "casting-like operations" in any popular dynamically-typed imperative programming language that applies to variables and nothing else?''

***** Why does it have to be limited to variables? Anyhow, here's an example to ponder: "$b=7;echo(getType($b).$b);$b=trim($b);echo(getType($b).$b);". As far as we can tell (output observer), the "value" does not change, at least not in a definitive way.

***** ''It's limited to variables for the sake of this discussion, because we're discussing variables.  In your example, the value in $b most certainly does change -- it changes from a numeric value to a string value.  Both the type and representation change from the original value.  Its type is obviously different, but its representation is also different.  Typically, the initial value is represented by -- in your example -- a four byte binary integer.  The result of trim() is represented by a two (or four, if its unicode) byte character string.  That's what getType() tells us -- it tells us the type of the value, which actually tells us the format of the value's representation.''

***** We don't know it's "binary integer". The developer cannot see direct RAM and if you by chance know that, it's only because you have inside info about the implementation. Further, even if one implementation of the language does use machine "binary integer" type under the hood, a different implementation might not; it may use all strings, for example, and the app developer cannot tell the difference if done right (without studying RAM directly, perhaps.) You are '''conflating implementation issues''' here. Please stop doing that.

***** ''I'm not conflating implementation issues, I'm explaining why getType() returns different strings when passed two different operand values that may otherwise superficially appear to be the same value.  If the "app developer cannot tell the difference", why does getType() return different strings for what appears to be the "same" value?''

***** getType() reads the type indicator, not necessarily what you call the "value representation".

***** ''Yes, of course, but the "type indicator" (i.e., the type reference) is there -- first and foremost -- to identify the type (i.e., the format) of the value representation.'' 

***** No disagreement there. I would point out that whether the "actual" byte-level format in RAM varies depending on the type indicator is an implementation detail that is typically not visible to the language user, and there are different ways to implement/model the same thing, with various performance and interpreter engine design tradeoffs. -t

***** ''True, but reference to a value's representation allows us to easily explain and justify why there can be a language where a value's getType() returns "integer" in one circumstance and "string" in another, for values that otherwise appear to be identical.''

***** I disagree with your assessment of "easy to explain" in terms of comparing different models. You are a poor specimen to test WetWare (grokkability) issues because of your background and personality. You perhaps may be a genius at symbol manipulation, but as a test of common developer wet-ware, you are a very shitty choice. To be fair, ANY (alleged) professional interpreter/compiler writer may be tainted by their implementation experience so as to not be a good reference source of "typical developer" opinions and notions of types etc.

***** ''You appear to be relying on an AdhominemAttack to make your argument rather than evidence, and thus it is unusually ineffective.''

***** We've been around and around on this issue before in sister topics. Neither side can present solid studies on developer wet-ware such that all we have is an AnecdoteImpasse. Thus, we can't precede any further on claims of "easy to explain" (your words). I ran out of new evidence but I have plenty of new AdhominemAttack''''''s left, so I use them instead. See, all very logical.

*** It's moot anyhow if the population doesn't accept it as reflecting their notions. It's merely a personal definition for personal use. No use quibbling about the definition of definition if the public hasn't recognized a definition candidate regardless of whether it really is a definition of not. Even if it's a model instead of a definition that's not a problem if our goal is an "explanation tool" (ET). Whether this ET uses definitions or models or a combo is not really the issue after all. The real issue is its usefulness as an ET in terms of 1) clarity, 2) accuracy, and 3) grokkability. Perhaps these 3 are not all optimize-able at the same time such that we'll have to find the best balance.

*** [You clearly don't know what formal logic is. If you knew what it was, you would already know about the connection between languages and models. You wouldn't write and endorse the drivel on ItemizedClearLogic. You would know that definitions aren't arguments, let alone fallacious ones. (You've, in the past, argued that definitions are an ArgumentFromAuthority.) Now, are you going to provide the evidence to back up your statement about there being problems with "type indicator" or not?]

*** I won't be suckered in by your AdhominemAttack. It doesn't appear at this time that whether your definition of "type indicator" is "formal logic" or not is relevant to the topic, and thus I won't focus on that for now.

*** [What AdHominem? And your response just provided more evidence that you don't know what formal logic is. If you did, you would know that a definition isn't a logic, formal or otherwise. Anyway, you brought up formal logic when you started talking about models in mathematics. If you don't consider it relevant, why bring it up?]

*** I may have inadvertently introduced off-topic issues. I will review later for relevancy. If it turns out my fault, you are then free to spank me, but only if you buy me dinner first.

** So Microsoft's C++ is not "valid" C++? I'm approaching this from the language user's standpoint, and they generally '''don't care about and can't see the implementation'''. If a new vendor makes a compatible interpreter/compiler, and it "runs" their code fine, it's '''considered equivalent''' to the vast majority. That's my '''working assumption''' here. If you want to reason using a different working assumption (implementation-centric), be my guest, and we can then LetTheReaderDecide which working assumption they prefer to use. -t

** [I see you've avoided answering the questions. By this, I will assume that you can't point out a real issue with the definition of type indicator. To answer your question, if by "valid" you mean what the C++ standard refers to as "conforming", then yes, Microsoft's C++ is not valid. And it's not just a matter of being slow to implement the standard (which they have been), but also a matter of choosing to do some things differently. E.g. There are differences in name resolution in templates. Obviously, whether or not ones C++ code runs fine will depend on whether or not they make use of features that Microsoft does differently (including not implementing at all). What does this have to do with our discussion?]

** If there is a formal "standard" by which Microsoft C++ fails against, then THAT is a better reference point than implementations. This relates to the issue of whether to define a language's type system by actual implementation of the interpreter/compiler, OR it's externally observable behavior (IoProfile). I use the second and you appear to use the first. I don't care about "the guts"; they are swappable for different guts without breaking existing apps. You are picking the wrong abstraction level to base type-related vocabulary around. (I will address the "water cooler" question above.)

** [The formal standard is described in terms of an implementation on an abstract machine. This particular issue isn't relevant to the IoProfile, it comes from your, rather surprising, claim that typical programming languages aren't defined in terms of implementations. I gave your 4 languages that I consider typical that are (or were), and asked you if you considered them typical.]

** "Abstract machine"? You mean along the lines of TopsTagModelTwo? And without a survey of programmer (language user) opinions, we only have an AnecdoteImpasse about what they think of language reference points. I stated my working assumption regarding that issue. If you don't like it, I don't give a shit. As a language user, I want '''description parsimony''': The simplest and most-approachable explanation that helps me '''predict''' what the language parts do (behave) in programs. Reflecting actual under-the-hood implementation of the interpreter is not a priority. '''I'll take a simpler UsefulLie over a bloated truth''', and believe typical developers I encounter will agree. Roughly 95%+ have no plans to be a professional interpreter maker and thus will live with a UsefulLie if it simplifies their life.

** I should point out that having a reference implementation to create a single reference point, and using or not using implementation to document the type system are generally two different issues. The first's primary purpose is to solve sticky edge cases/disputes, while the documentation "model" is to explain in a way that developers can relate to. One shouldn't have use actual implementation for the doc anymore than the documentation should talk memory cashing and expression evaluation stacks (except maybe in the performance section).

** [Yes, C++, C and Java are all defined by an implementation on an abstract machine. Unlike TopsTagModelTwo, they are fleshed out enough to define the language's behavior (at least to the extent that the languages designers' wanted to define the languages). What are "language reference points"? The rest of your rant appears to be irrelevant (what you want doesn't change how the languages were defined) where it isn't inaccurate (the primary purposes of the abstract machines under discussion is to define the languages under discussion).]

** By "language reference point" I meant what regular developers consider the reference in a practical sense. Even if the language is specified in way similar to how C et. al. are, that won't matter to regular developers; most are not going to read that. I could flesh out TopsTagModelTwo more, but then it's less approachable to regular developers. There is perhaps a trade-off in terms of thoroughness versus brevity (or quick absorption). I know you have many gripes about TopsTagModelTwo, but C's approach won't cut it.  Also note we are talking about dynamic languages, and C, C++, and Java are not one. -t

** [At this point, we were talking about "typical" languages. But there's still older versions of Perl if you want to restrict it to dynamic languages. Anyway, it would have been clearer if you had said "reference" instead of "language reference point". I can now put that bit of your response in the irrelevant bin.]

** I'm talking about dynamic languages. Static/compiled languages have decent type-related documentation, for the most part. The real problem is dynamic language documentation. 

** [I will note that you originally were willing to talk about C, C++, and Java until just recently. Why the change? If you only want to talk about dynamic languages, what about Perl? If the real problem is language documentation, why complain about the definition of "Type indicator"?]

** It was probably a mistake on my part. It's a side-track that went nowhere. I was basically trying figure out what you were talking about by asking questions, and it turned out to be about nothing. You are the Jerry Seinfeld of types. What's your Perl point exactly?

** [I am trying to figure out how the languages that are defined by an implementation fit into your view that languages aren't typically defined by implementation.]

** PageAnchor Topic-Rename-01

** First let me clarify that being defined by a virtual machine is not necessarily "being defined by an implementation", at least not in the sense we've been talking about in the past. Second, definitions happen in human heads, and may be relative to human. Third, languages users (app programmers) don't necessarily care about a formal "language definitions". They want languages manuals that convey ''to them'' how the language behaves so they can predict how programming code will process input. They will not typically care about a formal virtual machine language "definition". You seem to be losing sight of the '''target audience'''. Perhaps the title of this topic should be "Type documentation smells badly". I'm open to a renaming it, if you find the topic name an issue. If you wish to claim that a virtual-machine-based-definition (if it's even a definition) is formal, clear-cut, and/or good enough from an academic perspective or compiler/interpreter-writer perspective, I won't necessarily challenge that here and now because it's not an issue I care about here. I care about typical developers using language manuals which intend to target developers who are ''using'' the given language, not making it. I don't give a flying shit about compiler/interpreter writers at this time. -t

** [I don't see how one could define something by a virtual machine and not define it by an implementation. Could you give me an example of such a thing? Nothing in your response appears to have any relevance to how Perl fits into your view that languages aren't typically defined by implementation.]

** Again, I'm not clear on what Perl has to do with anything. From '''the perspective of a typical developer''', if a different vendor or interpreter-programmer created a new implementation of Perl from scratch that ran existing Perl programs just fine (same IoProfile), typical developers would CONSIDER it the "same language" or "runs the same language", as long as compatibility is not a concern (real or perceived). Where do you disagree? 

** Granted, Perl perhaps "leaks" C or implementation-specific artifacts that make cloning very difficult. But if the behavior is tied to specific underlying technology or goofy tweaks, then perhaps one is stuck with that ugly fact. It's a poor way to design a language, but reality is often ugly. But also, a type model may not have to be 100% perfect to be useful. Like I mentioned elsewhere, sometimes a simpler UsefulLie is better than a 100% accurate but messy truth. Ideally we'd give the reader the '''choice of both''' (with appropriate caveats): the simpler-but-imperfect model AND the 100% accurate but obtuse or verbose model: they can then choose which they want to use. LetTheReaderDecide which "mental tool" they use. It's roughly comparable to Newtonian versus Einsteinian physics: one is simpler but less accurate. One can perhaps present it as such: "The following type model is accurate the vast majority of the time. However, there are 7 known exceptions, which are described as follows...". -t

** [You made a claim about how languages are defined. Perl appears to run counter to that claim. That is what Perl has to do with it. Now how does it fit into your claim? (I'll also note you were unwilling (and I'll assume unable until proven otherwise) to provide an example of how something could be defined by a virtual machine but not an imlementation.) As for where I disagree, I seriously doubt that the typical developer uses your IoProfile in any way. Secondly, in my experience, a developer would consider two implementations to be implementing the same language if they both had made reasonably good attempts to meet the definition of said language. I can't see how your second paragraph is relevant.]

*** Re: "I seriously doubt that the typical developer uses your IoProfile in any way." -- If they use successful runs of the shop's existing source code to judge a new interpreter/compiler, they are essentially comparing by IoProfile. (The written and "thru-the-grape-vine" reviews by various reviewers is part of this, as it kind of pools the reputation of and experience about the interpreter/compiler in terms of running existing software.) It may not be a formal version of IoProfile, but it's essentially the same thing. -t

*** [In the IoProfile page, you state that the comparison are byte-for-byte. Is it really typical for the developers you know to do byte-for-byte comparison on compiler output? Is it really typical for the developers you know to use anything that could reasonably called an "approximation to all" inputs when trying out a new compiler?]

*** See the bold title "Byte-for-Byte and Literalness" in IoProfile. -t

*** [I see you've changed your definition. I will now agree that your IoProfile is in widespread use. Using it is almost unavoidable. Unfortunately, the change in definition weakened it to the point where the concept of two implementations having the same IoProfile is pretty much meaningless. So now I disagree that typical developers would consider said implementations to be the same language if they have the same IoProfile.]

*** I am not sure what you mean. Please elaborate. I didn't change "the definition", I merely clarified. (The practical approximation issue was described before, but now appears to not have been sufficient.) I cannot anticipate all possible misunderstandings up-front, especially from somebody with such an odd, alien-like personality/point-of-view as yours. 

*** [Of course you changed it. Originally it was "byte-for-byte". After the last bit the comparison could be anything. I don't see how the latter could be a "clarification" of the former, unless, by "clarification" you mean "changing significantly". Anyway, the problem is now that, without changing the implementations or tests, you won't get consistent result about whether or not the implementations are implementing the same language.]

*** "Byte-for-byte" is the ideal, and in practice reaching that 100% may not be realistic just as testing every possible input is not realistic. I don't know what you are trying to get at. How close two language implementations are to each before a language user declares them "the same language" is subjective and probably usage-specific. I've found differences in interpreters between versions but the difference was not enough for me to say the new version "runs a different language" in a general sense and I'm pretty sure most developers would agree. You seem to have a problem with relativity here and want perfection-or-nothing. You seem to be quibbling for quibbling's sake, or at least it's a classic LaynesLaw spat over "same language". Nor have you offered a decent alternative for comparing.

*** [Whether or not I offer an alternative is irrelevant to whether or not there's a flaw in your approach. You claimed that this IoProfile could be used to determine whether or not the same language was being implemented. It now appears it can't be used for that purpose. And, no, in spite of your best efforts, I'm not arguing about the definition of "same language".]

*** I see trade-offs, not flaws. What exactly is this "flaw" in your own words? And what are the practical implications of this alleged flaw? Please be as explicit as possible, avoiding pronouns etc.

*** [Without changing the implementations or tests, the results about whether or not the implementations are implementing the same language won't be consistent. The relevant practical concern is the claim that the IoProfile can be used to determine whether or not the same language was implemented is clearly false. Sometimes, comparing the IoProfiles will result in the implementations being declared the same and sometimes comparing the IoProfiles will result in the implementations being declared different. The different results can happen even if no changes have been made to the input or the implementations.]

*** If I interpret what you are trying say, what you are saying is false.  Can you give a specific example scenario of this alleged inconsistency?

*** [Ok, Some people look at a pair of IoProfile''''''s and say, "Clearly they are from the same language.". The next group (possibly consisting of the same people) look at that pair of IoProfile''''''s and say, "Clearly they are from different languages." (Note: The actual IoProfile''''''s are irrelevant.) Now, how can I use it to determine whether or not two languages are "the same" when stuff like that can happen?]

*** I'm not sure what you mean.  Can you give a '''specific''' example scenario of this alleged inconsistency? For example, give example code or I/O text that would make them say the phrases you claim they would speak so I know what these speakers are looking at to trigger them to speak those things.

*** [What irrelevant bit of detail are you looking for?]

*** Double-huh?

** No, running their existing fucking code the same is the most important to them; whether the "cloner" used "the definition" (whatever the hell that is) or chicken entrails to achieve that goal is secondary. I'm not sure what you are talking about in the rest of that paragraph. It's too general.

** [You don't know what a definition is? Well, no wonder you're confused. Go learn about definitions before continuing. And, how is asking you about a specific claim you made in relation to a specific language too general?]

** I meant wherever the actual definition of a given language is, not the general sense of what "definition" means. Developers only care IF an interpreter runs their code as expected, not HOW. If that differs from your experience of how developers measure if an interpreter "runs" the same language, so be it. 

** [Why is what others care about relevant to your claim about how languages are defined? There doesn't appear to be any relevance.]

** Wrong. Definitions generally require "buy in". Anyhow, I wish to get away from what may be the "official definition" (if there is such per language) and focus on the documentation for '''language users''' (regular app developers). I don't care about interpreter/compiler writers or experts here; they are NOT the target audience of my concern. If you feel this conflicts with the title of this topic, then let's consider a split or rename (per above at PageAnchor Topic-Rename-01). -t

** [It fine by me if you want to drop this sub-topic. I'll just treat the claim in question as false since there's a counter-example and you aren't willing to deal with it. BTW, whether or not a definition requires "buy in" depends primarily on whether or not you want the term to see general use. Terms that are local don't require it, and can be used simply by telling people that's what you want to use. With regards to languages, the only people who need to "buy in" are the designers of the language. Furthermore, any language without an official definition, is, de facto, defined by its implementation. (Further evidence that your claim you no longer wish to discuss was a false one.)]

** I'm not sure what counter-example you are talking about. Learn to use named references; they are good things. And I disagree with your designer-centrism. '''Users of tools get to define/declare if tool A is equivalent to tool B (for their own intended use), NOT the tool builders'''. I'm not necessarily looking for an official standards body; I'm looking for ways to convey TypeSystem behavior to typical program language users. If you have a different goal, so be it, but I won't necessarily want to assist you with that goal. --top

** ''If you want to convey TypeSystem behaviour to '''typical''' programming language users, you'd likely be much more successful if you picked one language at a time -- say, PHP -- and wrote a new manual or a supplement to the existing one(s).  For a typical programming language user, your TypeSystem model at TopsTagModelTwo is more abstract and complex than the language he/she is struggling to use.  If you want to convey TypeSystem behaviour to programming language users with a broader and more in-depth interest, they'll have no difficulty with ComputerScience texts like the StructureAndInterpretationOfComputerPrograms, various texts on TypeTheory, or descriptions like TypeSystemCategoriesInImperativeLanguages.''

** The conceptual difference between say Php and JavaScript is not different enough to justify a completely different approach in my opinion. "Solving" documenting for one will likely be applicable for the other. As far as which existing candidate sources are "the best", we've been over that already. None of your references are even near being of a sufficiently quality in terms of their ability to explain clearly to typical developers, in my opinion. I don't want to re-squabble those document opinions here. Your background and thought process differs too much from "typical developer" such that '''you are not a good human test specimen''' for such documents. (This is not a quality-of-person judgment, ONLY a statement of being a ''representative'' sample as far as "testing" or emulating the target audience.)  -t

** ''There may be no conceptual differences between PHP and JavaScript, but if you want your target audience to appreciate your explanations, you're more likely to be successful if you create two manuals -- one for PHP, and one for JavaScript.  I'm sure it won't be much effort; with a good template-driven document authoring &/or management system, you can probably boiler-plate the majority of the text and insert the strings "PHP" or "Javascript" -- along with language-specific examples -- where appropriate.''

** It can be tested and perfected in one before done on the other. Otherwise, we risk doubling the mistake.

** ''Yes.  So?''

* If you are claiming it's possible to mirror the behavior of tagged languages without tags, well, that's an interesting question. It will probably come down to how "tag" is defined because I strongly suspect that ''something'' in the model will be functioning as a tag in some manner. For example, somebody suggested storing the quotes from the assignment statement as part of the "value", and strip them off in WRITE statements. But those quotes are essentially a form of tag. They are "storing" type-related info separate from the "value" portion (the stuff inside the quotes).

* ''The characters of a literal can certainly indicate the type of the literal.''

* Well, that depends on how one defines "type of". We've had this debate over ColdFusion's parameter filters.

* ''Actually, no, it doesn't depend on how one defines "type of".  It depends on how a given language's TypeSystem is defined.''

* Which is usually poorly.

* ''Really?  Note that I wrote "'''defined'''", not "'''documented'''".  How a language is defined determines how it works.  How a language is documented may not reflect how it works, or describe how it works, as well as we'd like.''

* What exactly do you mean by "defining a language"? It sounds like you mean "implemented", not "defined". Anyhow, if we cannot observe this alleged "definition", then it's not useful to us, the language user.

* ''In short, how the characters of a literal indicate the type of that literal depends on how a given language implements it.  For example, in many programming languages, 'piffle' or "piffle" are string literals.  However, some SQL DBMSs treat 'piffle' as a string literal but "piffle" as an identifier.''

* Okay, but most dynamic language manuals poorly describe the specifics of such. 

* ''If so, the problem lies with technical writing, not TypeTheory or TypeSystems.  What's needed is better writing, not new models.''

* If you can use TypeTheory to make the writing better, be my guest...


Your so called "TypeTheory" does NOT dictate or formalize how its category models (and related vocabulary) tie to '''specific''' programming languages in clear-cut ways. Just about everything ''can be'' viewed as a type or category, but calling or modelling everything as such may not make sense to the front-line programming troops and not necessarily match colloquial vocabulary and field language. TypeTheory can be potentially used as part of a specific model(s), but the formal connections between it and actual specific languages are still missing.

''What makes you think so?''

I believe you even agreed that the language designers/authors/vendors get to '''call parts whatever they want''' to and may even violate the canon (if there is such).

''You can call the parts whatever you want.  However, there are terms used by convention, because conventions in language are what make communication possible.  If you deviate from convention without careful clarification, you only cause confusion.''

The "convention" is fuzzy. We've been over this before in the "value wars" topics. You cannot produce clear-cut algorithms/rules/formulas for identifying occurrences and non-occurrences of various terms. I don't want your summary opinion, I want solid codified rules IN TEXT so that I don't have to rely on the black-box notions in your stubborn and biased head. You just make round-about excuses for not providing the codification.

''No one can produce "clear-cut algorithms/rules/formulas for identifying occurrences and non-occurrences of various terms", because every language term inevitably results from an infinitely-recursive chain of terminological references.  Even a simple example from geometry -- which is about as "clear-cut" as you can get -- demonstrates this.  Take "triangle" (from WikiPedia): A triangle is "a polygon with three corners or vertices and three sides or edges which are line segments."  What's a polygon? "[A] plane figure that is bounded by a finite chain of straight line segments closing in a loop to form a closed chain or circuit."  What's a plane?  What's a line segment?  What's a corner?  What's a side?  What's a loop?  What's a line segment?  What are vertices?  What's a three?  And so on.  Imagine trying to produce "clear-cut algorithms/rules/formulas" for that.''

* That's a valid point (no pun intended), but at least the second-level of definitions are things both parties are likely to agree on in practice. No use arguing over things two parties already agree on. "Types" doesn't have anything close to a common second level. The sub-parts of sets have '''no comparable object''' to "vertices" etc., and thus your analogy fails. "Sets" are probably the closest thing, but everything can be viewed as sets, including typical functions, such that it doesn't clearly fail/exclude anything. There's no falsifiability. It reminds me of Creationism: "X is that way because God wanted X to be that way". Sure, it "covers" everything well, but is not scientifically testable because there are no observations that would falsify that model. '''We cannot say what are NOT types'''.

* ''Really?  A common (informal) definition of a type is that it is a set of values and associated operations.  In some respects, that's easier to identify than a triangle, but maybe that's why I work in ComputerScience and not geometry.  Aren't the second-level definitions -- set, value, operation, and associated -- straightforward?''

* Like I've pointed out before "operations" can be viewed as mappings (look-ups), which is wide open. And are we talking about known operations or future operations (such as user-defined functions)? In colloquial-land, the "operations" one considers tend to be '''situational and topical''': its "type" is considered in terms of a specific usage/function/situation. With "$x='123';", $x can "be" (considered) numeric in one situation/function, but not in another. The situational relativism is fine for colloquial situations, but won't produce anything rigorous AND useful AND universal at the same time because it's a moving target. There's a general "scoping problem". And we've had problems with the term "value" and "associated" before. Everything in the observable universe is "associated" in one way or another such that we need to agree on a specific context and "rules" and/or notation for when "associate" is happening and when it's not happening. There's nothing solid enough in colloquial-land to use as a foundation, and your personal interpretations of what to deem "associated" appear randomly pulled out of your ass based on obsession with some obscure narrow little issue that probably only matters to you.

* ''These have all been discussed before.  The definition is an abstraction, admitting a wide scope of implementations.  A type is meant to be as identifiable in Haskell or Prolog as it is in C, APL, or a language you invent.   There's nothing in the definition, for example, that precludes types overlapping unconditionally, or overlapping only in certain contexts.  Perhaps you find that breadth unsettling?''

* Unsettling, no. Too open-ended to be useful in the practice of typical programming, yes.

* ''That's why language documentation typically describes the abstraction in terms of the language.''

* The type-related language documentation is typically bad for dynamic languages. What's needed is a '''documentation framework''' for typical dynamic languages so authors stop mis-inventing their own.

* ''What would such a "documentation framework" look like?''

* I'm not entirely sure. There may be more than one way to do it. Explicit reference to a type-tag (indicator) and clarity between it and parse-based typing would greatly help in my opinion.

''The solution here isn't a set of rules.  Indeed, for types and other things, we've sometimes given definitions in terms we understand and you rejected them.  The solution is to read more.  Then you'll learn more and understand more.  I don't know why you find that so objectionable and appear to be offended by the suggestion that you read more.  Reading more is how humans learn more and understand more.  It's a GoodThing; nothing bad could possibly come of it.  It would certainly give you greater (and, I suspect, more satisfying and less frustrating) understanding, and if you wished, it would give you a '''much''' stronger foundation from which to launch objections to aspects of theory or industrial practice with which you disagree.  If you continue to lob weak objections at TypeTheory or ObjectOrientedProgramming or HigherOrderFunctions or PreparedStatements or whatever with what is obviously superficial knowledge, you'll be increasingly ignored and marginalised.  However, if you object from a position of strength -- armed with in-depth knowledge and a firm understanding of TypeTheory or ObjectOrientedProgramming or HigherOrderFunctions or PreparedStatements or whatever -- you'll have a fair chance of being heard, and maybe even convince others that you're right.''  

Everything else I claim I can explain in terms of standard logic and math. True, the givens may depend on anecdotal evidence and assumptions about human behavior, but I PROCESS the base givens with standard logic and math to make my conclusions: there are no "spooky steps". If you disagree with the base assumptions, that's fine; at least we agree on the SPECIFIC part of the model where the disagreement lies. But there's nothing even close with "types", per current writing.

I truly believe you mistake your internal head notions/models for universal truths, and that is the real problem and that's why you cannot articulate your claim/reasoning steps: '''you are using a "reasoning language" that only compiles in YOUR head'''. Telling the other guy they "don't read enough" is a copout. Explaining properly is explaining properly. '''It's the writer that is broken, not the reader!'''

''Where have you used standard logic and math?''

* ValueExistenceProofFour

* ''I looked, and see neither.  Where is the standard logic and math?''

My goal is not to "get it", my goal is to document it so everyone knows the names and relationships between the parts and rules of the type model: old-fashioned western reductionism.

''How do you expect to document it if you don't "get it"?''

I'm not sure I have to "get it", I just want to document the rules and parts. "All floobs are also mips unless they belong to the set of snerks, and you can tell if something is a snerk if it produces muups when combined with blups" type of thing. Whether I "get" what "floobs" are is secondary.

''How do you know you've documented it correctly, if you don't "get it"?''

Contradictions are discoverable with clear writing. If statement 12 says "Floobs can be mipps only if they don't have sniggs" but statement 47 says, "Floobs can be mipps and have sniggs if they are purple", then we have a logical contradiction (or a useless statement about something that can't exist.)

''If you don't "get it", how do you know you don't have logically consistent nonsense?''

One can identify the logic contradiction in the "Floob" statements '''as-is'''. No need to "know" what a Floob is. They can probably be converted into formal mathematical set notations and processed by a machine to detect contradictions even. (We may have to settle on what "has" means in terms of sets, first. "Has" was a stumbling block for us before in the "nested" fight.) Don't ask me to do it though, I'm rusty at that stuff.

It's not much different from homework in school where you have something like:

  1. x belongs to the set Y
  ...
  5. x does not belong to the set Y.
We don't have to know what x and Y are to know that we have a contradiction in statements #1 and #5 (assuming they don't change in time). True, it's nice to have knowledge about x and Y, but not a requirement to apply reasoning and derivations to rules about things.

{You didn't get his question. "An apple belongs to the set of oranges." without the contradiction is logically consistent, as is "A cat belongs to the set of dogs". But does it make any sense?}

You are correct, I read it wrong as "logically ''in''consistent nonsense". My bad. I'll worry about that issue AFTER somebody submits a logically consistent working set for inspection. Of course the model has to reflect common or typical notions of "types" to be accepted (in common and typical languages). But '''at least''' present a clear set of rules/formulas/algorithms.

''See TypeSystemCategoriesInImperativeLanguages.''

PageAnchor TSCIIL-critique

It's not clear how to relates to a specific language or gives anything useful. It may be producing UselessTruth''''''s at best. 

''Examples of specific languages are given, but we can LetTheReaderDecide whether it's producing UselessTruth''''''s or not.''

* Fair enough.

And it hasn't been vetted by known experts. 

''Who would you like to have vet it?''

D1.3: "at least one type" but later says "finds a T" (D1.8), implying only one. 

''That is correct.  If a given literal belongs to more than one type -- e.g., a 0 could denote an integer, float, or boolean -- one of them is chosen arbitrarily.  In many languages, the literal 0 is arbitrarily chosen to be an integer.''

* That should be made clearer.

* ''Admittedly, the section in which it appears could benefit from some English explanations.  The semi-formal treatment is accurate, but could benefit from some examples to put it into context.''

D1.9 "program...can determine..." How exactly and where does one go to see this? 

''An example is immediately below it.''

And your "V" is not anything objectively observable. It's a fictitious middle-man that may not even be necessary, complicating the issue. 

''V is standard terminology, used in a conventional manner.  It represents the result of an expression evaluation.  It's a term for the result of a + b, for example.''

We've been over this already. "Value" is overloaded and vague.

''What would you suggest as an alternative?''

If it's not needed, don't mention it. If it's only needed for expressions, then only use it for expressions.

''It's also needed for what functions return, what variables store, and what literals denote.  It appears in the majority of programming language documentation, which would lead the reader to expect to find it in a model or abstraction of programming languages.''

The documentation does not endorse your viewpoint on the data structure of variables in a clear way. You just think it does because you read stuff with a biased eye.

----

If you need to argue the meaning of "value" I cannot see how you can have any hope of discussing any programming language. Until you can agree on a useful interpretation of "value", you should refrain from discussing the rest. Maybe you should also agree on the meanings of "is" and "has" too. -- ChaunceyGardiner

''Agree on with who? Mr. Nohandle has insisted that the type indicator ''must'' be a sub-part of "value" (if type indicators exist). I invited Mr. Nohandle to provided cited evidence that this interpretation is canonical, but so far nothing concrete has appeared, let alone the volume of citations that would typically be expected to qualify as a canon. (A couple of quotes were given, but were not even close to concrete per my interpretation of human English.) In practice, "value" is defined loosely and can take on and exclude various characteristics ''per situation''. I have no problem living with vague notions for these kinds of things since "clinical" definitions don't exist yet, but Mr. Nohandle feels his pet versions of these are the OneTrueWay. I do NOT insist that my model/interpretation of type-related parts are canonical, ONLY that they provide program-behavior prediction capability. -t''

''As far as "is" and "has", types sometimes remind of the quantum world. Light can take on the properties of both waves and particles, depending on the experiment. When light is acting like a wave, can we say light "is" a wave? Can it "be" both? The actual usage of type-related language is similarly situational, sometimes in seemingly contradictory ways. "1" (one) can be interpreted as a Boolean, a String, and a Number, depending on the operation or using function. However, a function such as get_type() may give one and only one answer. Thus, "1" may "be" Boolean in one situation, but not another. Regular English is not giving us enough precision to distinguish between these.''  

I would put a very large STET on my above contribution, and a very large HUH on your consequent rant. The VALUE 1 can have many different meanings in code, depending on its type, or where it occurs. We are not researching quantum physics - though your wave analogy shows that types can overlap. I strongly doubt that any Mr. Nohande would say that a type is a sub-part of a value. And this - "value" is defined loosely and can take on and exclude various characteristics ''per situation'' - demonstrates why we need types - those characteristics are disambiguated by their various "type" situations.

''They are disambiguated by what? Please clarify which person, place, or thing. If they are situational, then documentation should have a decent way to describe the situations in effect in a clear way. And/or invent language for the two different approaches to "types" common in dynamic languages. I'll let Mr. Nohandle comment further on his opinion regarding the relationship between type indicator and value.''

[A value V is a representation R -- typically a string of bits -- associated with a reference to a type T.  The association between R and T is necessary.  R without T is unidentifiable, e.g., what value is 01100110011010010111001101101000?  Is it an integer?  The ASCII string "fish"?  A floating point value?  T without R describes a set of values such as "string", but not a specific value.  Together, e.g., V = (01100110011010010111001101101000, string) is "fish".]

We've been over this already. There is still a machine-processable (unambiguous) association between the type indicator and the "representation" in the alternative: <variable name="myvar" type-indicator="number" value-representation="123.45"> -t

[That may be an appropriate -- though perhaps awkward -- model for a variable in a StaticallyTyped language.  How do you model the result of evaluating 2 + 3 in a DynamicallyTyped language?]

* As generating a value-representation and a type-indicator.

* [A value-representation associated with a type-indicator is a value.]

** So you say.

** [So I've proven, above.]

** You don't know what real proofs are. You are just a B-grade wordsmith.

** [Your response is nothing but an AdhominemAttack.]

* The intermediate result is usually of such a small concern in language-user manuals that introducing a middle-man container/structure is not worth the extra layer, in my opinion.

* [Except the term "value" shows up frequently in language-user manuals, as does expressions, returning values from functions, and storing values in variables, no?]

* Yes, because it's overloaded to mean different things (or variations of the same ''general'' notion). "Result of expression/function" is also common. Thus, "result" is sufficient. In general language-user manuals seem hesitant to dictate or even suggest a data structure(s) for such. Those who insist there is a standard/common data structure to be found in the manuals are probably full of themselves and high from sniffing the hallucinogenic fumes of their own stubborn brain.

* [Coalescing the (apparent) variety of terminology or (apparent) terminological overloading into a single, unambiguous definition of "value" is what I've done at TypeSystemCategoriesInImperativeLanguages.  There may not be a common "data structure" for values "in the manuals", so I have provided one that encompasses what all the manuals (for popular imperative programming languages, at least) are trying to get across.]

* Are ''trying'' to get across? I put that in the "try" camp also. So, who elected you the ''type whisperer''?

* [Huh?]

[And, yes indeed we've been over this already.  Why, then, did you write that you'll "let Mr. Nohandle comment further on his opinion regarding the relationship between type indicator and value" if you didn't expect me to comment on my opinion regarding  the relationship between type indicator and value?]

If your response is a link, that's fine by me. Respond how you wish.

[You specifically requested a response.]

A link is a response, Mr. Quibbly.

[Ok, here's a link: TypeSystemCategoriesInImperativeLanguages.]

I was thinking more like ValueExistenceProof and its chain of related topics.

Note that it may be convenient to define/model a "container" for containing type indicator and value representation for intermediate results, such as the "result of an expression (evaluation)", but that does NOT mean this container ''needs'' to be "inserted into" a variable structure as-is. But generally that's an arbitrary (non-mandatory) model/implementation decision and not an absolute requirement. -t

----

''later-day JavaLanguage has no Idea<?> what ur talking about.'' 

and if templates force a re-interpretation of a template into a produced class, why _can't_ Java templates use pure data arguments? Otherwise why not just use references to types? Funny how the less-is-more languages don't suffer a combinatoric explosion of redundant paperwork to redefine all the types. For kicks, select part of an odd typing expression in EclipseEditor and hit ExtractLocalVariable. boom - bits of aircraft & hanger scattered everywhere. --AnonymousDonor

----
'''Arbitrary-ness to get Concrete-ness?'''

It may be that documentation may have to settle on somewhat arbitrary models, representations, and/or definitions in order to provide a concrete system to present types in a fashion that's grokkable to readers. Our disagreements over how (or if) to represent "values" may pivot on this issue. I have nothing against arbitrarily picking a specific model/technique to describe types to improve communication, but it should come with the '''caveats''' that first, it is a somewhat arbitrary choice, and second, it probably cannot be considered a "canon" (until widely adopted, which is not an initial primary goal). -t

This can be roughly compared to music notation: there are multiple ways to represent and describe music, such as the traditional dot-and-staff notation, and the "piano roll" view made popular by software sequencers. But the dot-and-staff notation is currently the de-facto standard and is the reference source model used for most descriptions of music when a certain degree of explicitness is desired or required. -t

See NoTypeCanon for more on this.
----

I smell badly at the moment because I have a cold. Which is a shame because I've been told my socks smell bad. --AnonymousDonor

----
AprilFourteen