Wysiwyg Type System Discussion

Continued from ColdFusionLanguageTypeSystem

In the development context, yes. The debugger/console essentially has logic similar to : if (targVar.typeTag==STRING) {consoleResult = QUOTE + targVar.toString() + QUOTE;}. It's essentially a "friendly" way to echo the explicit type indicator. By WYSIWYG I mean there is nothing separate from the "value" or "representation" that affects IoProfile (observable language behavior). Further, debugger/console behavior may be implementation-specific such that a different vendor may display it different or without such type hints in their gut-displaying tools. It's courtesy info, not part of the language definition itself. -t

[Hmm. As far as I can tell, it's true that the console display of various values in JS isn't standardised -- there is at least a definite de facto standard in that all major implementations display values in-console in terms of their literal syntax, as I describe, rather than a user-facing string conversion. Your distinction between the "value" and a somehow-separate type seems rather misleading: A representation is entirely meaningless without some indication of how it is to be interpreted, as a type provides, and since representations are strictly opaque and also not observable using them as a (the?) descriptor of observable language behaviour strikes me as odd. -DavidMcLean?]

Why is it "meaningless"? Tag-free languages do just fine without a (detectable) type indicator. It's typical that dynamic languages use context and programmer convention to "define" meaning/usage, rather than "intent" explicitly defined to the machine. And while I agree that the "machine-level" implementation can often be undetectable and/or interchange-able to "outsiders", whether one models or thinks about "objects" (values, variables, etc.) as having a singular content "slot" or a separate "type slot" from the "value slot" may be a matter of personal choice and/or modelling parsimony. Something that ACTS LIKE it has a separate slot from "value" or "content" (in most cases) is not WYSIWYG because if you only see the content, you are not seeing the type slot (or a clear equivalent), and thus are NOT getting what you see (WYSI*N*WYG). There is a hidden part or mostly/usually hidden part. A debugger/console may always show a clue to the type indicator, but that's sneaking in the back room to see Mr. Oz manipulating the projection of the face he shows to "regular" users. Anyhow, I choose NOT it define a language by what a debugger/consoles shows for reasons already given, and that's my working frame of reference on this wiki. As a reality test, if a vendor released a language interpreter they called "JavaScript" but its console didn't have such type-clue features, most developers would STILL call it "JavaScript". Therefore, the console and its output is NOT a defining feature of "JavaScript" for users of JavaScipt? (app programmers). (We've had this discussion already somewhere in the "value fights" I'm pretty sure.) -t

[Representation is meaningless without some indication of how it is to be interpreted because a "standalone" representation looks like this: 10101011110110110110101011101101110 (Maybe. A standalone representation could also look, say, like this {{}, {{}}}, if you're working on paper or using an unusual machine architecture. Generally, representation can have essentially arbitrary form, with no obvious resemblance to the value thus represented.) There's no way to know whether it's a string, or an integer, or an IEEE floating point number, or a bitmask, or anything at all. Associating the representation with some type gives the language the ability to interpret said representation meaningfully and hence make use of it. "tag-free" languages, as you call them, associate scalars' representations with the "string" type contextually -- there is indeed no need to "bundle" the type with the representation under such languages, apart from the indication that a given value is a scalar rather than an array, hash, object, whatever, but this is only because the language already knows that all scalars are strings with a particular representation. Treating the user-facing "display" formats as the be-all and end-all of values' forms borders on the absurd, considering that values can be displayed in any form desired for the application; if you must consider output rather than language meaning, focus on the literals that produce particular values (e.g., 1, 1.2, "1.2") since those unambiguously denote a particular, specific value by design. Indeed, a conforming JS interpreter could readily diverge from the de facto standard of displaying canonical string representations in the console, if it wanted to be unhelpful, but that doesn't render the canonical representations (as encoded in language syntax as "literals") any less canonical. (Oh, by the way, you may wish to switch analogies for your description of how debuggers give an "inside peek", considering that the Wizard's projection was the fake and that the man behind the curtain was real.) -DavidMcLean?]

Re: "if you must consider output rather than language meaning, focus on the literals that produce particular values (e.g., 1, 1.2, "1.2") since those unambiguously denote a particular, specific value by design." -- That's not necessarily true. In tag-free languages, 'a=7;' and 'a="7";' are completely equivalent as far as language behavior (unlike JavaScript). No known language operation can detect that one was assigned with quotes and one without. And I focus on what you call "output" instead of "meaning" because meaning is in the human head, not the computer. I focus on objective reality, not how (some) human may think about "types". You are again mistaking your internal pet head models for universe truths and/or canons. Calling something a canon does not make it so, nor does repetition of claim. Repetition is annoying, not truth. Anyhow, I define a language and type system (or lack of) by its IoProfile, and I believe most would agree, and I am going to keep doing it. If you want to define it different, that's your prerogative. Just don't paint it as a canon without stronger evidence or real surveys. Some will want to define "Oz" by what's projected on the wall, and others by what party crasher Dorthy and her rusted friends discovered in the control room. Let each have their way. But if a vendor comes along and replaces the professor but keeps the same projection style, the outside viewers may not know or care that he's been swapped.

[I claimed that a literal unambiguously denotes a particular, specific value by design. This is true, regardless of the fact that in some contexts the same value is denoted by two or more literals. In languages with a single scalar type, such as Perl, '$a = 7;' and '$a = "7";' are indeed equivalent, as both the numeric and string literals denote the same scalar; that doesn't stop literals from unambiguously denoting particular, specific values. Asserting that meaning exists in the human head is correct; asserting that meaning only exists in the human head is not. I believe this has been discussed on the wiki before, but the meaning -- or "semantics" -- of programming language constructs is well-defined and implemented in the language interpreter or compiler. Sure, it exists in the human head, but it also exists in the language specification and is objective and unambiguous enough to be processed by a computer. That which I describe as "canonical" is that described by language specifications and documentation, not by my "internal pet head models"; we have clearly canonical sources for programming language behaviour, since programming languages are constructed as an abstract, mathematical ideal. There's no need to infer or guess at how languages work based on their "IoProfile", because we built them and we know exactly how they work. -DavidMcLean?]

Exactly. Well put.

We were talking about types, not literals. Thus, I don't know why you are telling me "doesn't stop literals from unambiguously denoting particular, specific values." It appears to be off-topic. I don't see its purpose. And the language builders are not the target audience when discussing "type behavior"; and documentation on dynamic types is typically poor. Further, even if the interpreter builder used model/implementation X, there is nothing stopping a user from using model Y to "explain" or forecast language behavior, as long as the results match. You seem to want to beatify the builder's view. Remember our stack discussion? Interpreter builders are typically focused on machine-side issues, not human grokking. We've been over this many times in the Value Wars and I do not wish to participate in this dance again. -t

[We were talking about types and values and literals and all sorts of language components. I recommended you focus on literals rather than on a particular user-facing output format when considering values and their types, since literals unambiguously denote particular specific values, unlike user-facing output formats which often perform rounding and obscure other details of the value being output. In response, you claimed that's not necessarily true because two literals can denote the same particular specific value in certain languages, which is off-topic because I never suggested there's always a unique literal that denotes every particular value. Indeed, there are plenty of trivial counterexamples to that idea (1 and 1.0 are the same value in JS, for instance, as it does not have separate integer and floating-point types), but that isn't important because I don't insist there be a single literal resolving to a given value. If you have PHP's documentation in mind, I can agree that it's abysmal, much unlike every other popular imperative DynamicallyTyped language's documentation. There is strictly speaking nothing to prevent users from using any model they like to explain anything they like, true, but why bother? It's well-defined exactly how languages actually work; you don't need to construct an independent model to predict language behaviour, and if you're going to construct a model that has things like "anonymous variables", as I recall you bringing up in the "Value Wars", that's just proliferating (abuse of) terminology with no gain in clarity. -DavidMcLean?]
Well, maybe we can agree that both literals and user-side output are imperfect. WYSIWYG typing is not meant as a rigorous definition, only a general descriptive tendency. If you want to find holes in it, you can. But in aggregate, it usually holds. And quality of documentation is perhaps a subjective issue such that it's not worth bickering over. I personally find it poor. And the "anonymous variable" was an internal part. It's not unlike an expression evaluation stack, which is probably used under the hood in most languages, but otherwise doesn't need to be mentioned to (external) language users. It's an implementation detail or modelling choice. Both implementation and models can have it replaced by alternatives but the language IoProfile would remain the same.
[Since given a particular literal, you invariably know which value it denotes, they're a lot closer to perfect than simple output, which gives you no such information -- anything at all can produce particular output, after all. If "anonymous variables" are internal and aren't mentioned to users, what does your model externally say functions return, expressions evaluate to, literals denote, and variables store? -DavidMcLean?]
How exactly do we know what is "closer to perfect"? And I meant model user, NOT language user.
[We know what's "closer to perfect" by reading the rest of the sentence I used that phrase in. Given a particular literal, we always know which value it denotes, by design. Given some output, we can't necessarily know anything about where that output came from, since a particular output can be produced by so many different means. If "anonymous variables" are internal and aren't mentioned to model users, what does your model externally say functions return, expressions evaluate to, literals denote, and variables store? -DavidMcLean?]
Sorry, I am not following you. I suspect the problem is that you are mistaking your pet head model of intermediate internal processing for objective universal truths.
[Which part are you talking about? It's clear that literals unambiguously denote particular values, because the language interpreter (or compiler) unambiguously maps each literal to a value during parsing and analysis. It's also clear that output alone gives us no indication of how it was produced -- trivially, the string "hello world" could be output by printing a string directly, or by printing the individual characters one-by-one, or by writing a raw octet stream, or any of myriad possibilities. As for the last part, it was a question. What does your model say that functions return, expressions evaluate to, literals denote, and variables store? Is it values? Is it "anonymous variables"? -DavidMcLean?]
The first part is wrong. Values don't even have to exist. The fact that there are multiple ways to explain the output may bother you, but it may just be the nature of abstraction or modeling or implementation choices. There are multiple ways to model the same behavior. That's life. My model can call internal parts any arbitrary thing it wants as long as it's clear it's a model-specific name.
[The fact that there are multiple ways to explain output doesn't "bother" me; it just means trying to define the language's behaviour by its output doesn't work. And that first part is absolutely correct. Read any language's spec or documentation. Look at any interpreter. Also, you still haven't answered my question. What does your model say that functions return, expressions evaluate to, literals denote, and variables store? -DavidMcLean?]
"Doesn't work" for what? An orrery can call a particular gear a "Thoddledoop". Why do you care?
["Doesn't work" for correctly modeling language behaviour, naturally. Like I said, a program that outputs "hello world" could achieve that in any one of dozens of ways. If you don't distinguish between those based on the actual semantics of the language, you aren't usefully modeling language behaviour. Another example: A program that prints the first twenty prime numbers could calculate them, or they might be hardcoded. If you can't distinguish between those cases, you aren't usefully modeling language behaviour. -DavidMcLean?]
"Naturally"? There's a loaded one for ya. As far as the prime example, we've been over that already. You should be able to predict my response.
["Naturally" is loaded? I thought it was a pretty obvious implication that "trying to define the language's behaviour by its output doesn't work" means "doesn't work for correctly modeling language behaviour". Was that unclear? And no, we've never been over such an example before. -DavidMcLean?]
Define how you are measuring "correctly". Where is your Correct-O-Meter?
[Do you seriously believe "this program outputs 2, 3, 5, 7" is an accurate and complete description of language behaviour for both the programs "print('2, 3, 5, 7')" and "for (prime in genPrimes(7)) print(prime, ', ')"? -DavidMcLean?]
"Accurate and complete" description probably depends on context and usage. Why are we talking about comments now?
[We aren't talking about comments now. We're talking about modeling language behaviour. If you only take output into account, you get the same language behaviour for both of those programs. Do you consider that reasonable? -DavidMcLean?]
Like you forgot, IoProfile has an "I" in it.
[Both those programs take no input. -DavidMcLean?]
If they give the expected output, then users don't give a shit how they did it inside and everything is fine on Planet Earth. Done.
[So you're saying you do consider it reasonable to deem "print('2, 3, 5, 7')" and "for (prime in genPrimes(7)) print(prime, ', ')" equivalent programs? Really? -DavidMcLean?]
By "program" do mean source code or something like the executable? (Remember, I include source code in "I").
[The "program" is closer to the executable than the source code but is neither. Source code describes a program in a particular language, while an executable contains the steps needed to run that program; the program itself exists independent of its representation. If you include the source code in your input, wouldn't that mean that "for (prime in genPrimes(7)) print(prime, ', ')" and "for (primeNum in genPrimes(7)) print(primeNum, ', ')" are not equivalent programs? -DavidMcLean?]
The answer in practice probably depends on the intended use of object or perspective of the user, and arguments could be made either way. The source code is clearly "different" although the output may be the same. Somebody in charge of source code versioning may consider them "different" and somebody who only cares about the output "being right" may consider them the same.
[Under your model, are those two programs equivalent? -DavidMcLean?]
Under IoProfile, no, they are not equivalent.
[Do you not find your model problematic if it suggests that a program becomes an entirely different program as a result of a trivial variable renaming? -DavidMcLean?]
Every job position probably has a different perspective and no one (simple) metric can cover all those. Everybody is free to make their own profiler to fit their job, role, or desired perspective. I'm not going to force absolutism in a relative world.
[Why would equivalency of programs be dependent on perspective? -DavidMcLean?]
Because it is. Tools solve specific problems, and often different problems for different users of tools. End-users don't care about source code, for example, but developers do.
[I'm sorry, what? Under what conditions are the programs described by "for (prime in genPrimes(7)) print(prime, ', ')" and by "for (primeNum in genPrimes(7)) print(primeNum, ', ')" not equivalent? -DavidMcLean?]
In a practical sense, a given developer may consider them "not equivalent". If they learned a particular program from months of reading its source code, they don't want all the variables and functions renamed; that would throw them off. And they may not know if they are really equivalent; maybe one of the new names is an undocumented reserved word that can ONLY be discovered by running it? They don't have to accept the two as swappably equivalent because the second requires far more effort on their part. (I originally posted the wrong reply up there. Sorry.)
[But that's not equivalence of programs you're speaking of, but equivalence of source code. Renaming a variable (assuming no collisions are produced and that no mentions of that variable are "missed") produces new source code but not a new program. -DavidMcLean?]
How can you verify that without running it? (Such as per above undocumented reserved word scenario).
[By understanding the syntax and semantics of the language, and identifying that there are no behavioural differences between the two versions based on that understanding. If a reserved word is undocumented, it exists outside the language, which means the code before and after the variable rename are both valid ways to write the same program in the language; it's just that the particular interpreter being used is broken, if it won't accept the transformed version of the source. -DavidMcLean?]
Outside of YOUR definition of the language, which I reject, per below. From a practical perspective, a given programmer is rarely in a position to fix defects or oddities anyhow, and must rely on the interpreter as-is. For example, to them the thing which most call Php or whatnot does NOT run the name-adjusted version. They are not idealistic about should-be's, they just focus on problems in the field.
[You might use "Php" as a shorthand for "the Zend Engine PHP interpreter" -- such is quite common, although if multiple interpreters are being considered it's usually a good idea to specify (CPython versus Jython, MRI versus JRuby, and so on) -- in which case saying it doesn't run the name-adjusted version is both acceptable and correct. If PHP-as-in-PhpLanguage specifies that the program given is valid, however, then it is the interpreter at fault and the program is indeed correct. Given programmers indeed aren't really able to fix defects in the interpreter, but that certainly doesn't mean defects in the interpreter are not defects. -DavidMcLean?]
The vast majority of developers talking about "Php" are talking about the implementation(s), and NOT about any written specification.
[So? I just acknowledged that that's a perfectly normal thing to do. It doesn't change anything. -DavidMcLean?]
You are right, it doesn't: you are still wrong.
[Not at all. It just implies that in spoken language, words can have multiple meanings, which is well-established as well as completely unrelated to the crux of my argument. Whether the word "Php" refers to PhpLanguage or to Zend's PHP interpreter doesn't change whether the word "function" in PHP produces a for loop or defines a function. -DavidMcLean?]
PageAnchor Function001
IF "function" became in issue, then as described below, the implementation's actual behavior would trump it to most in terms of what Php "is". Thus, you are wrong.
[Not at all. Again, if the implementation behaves differently from PhpLanguage as specified, the implementation is not of PhpLanguage as specified. Trivially, A ≠ A'. You can even say the implementation is "wrong", as I did earlier in this discussion, because the implementation was intended to be an implementation of language A, but instead it became an implementation of A' -- it solved the wrong problem, in a sense. The term "PHP" in natural language often refers to the reference implementation, that being the Zend Engine interpreter, but also can refer to the language-as-specified; if there's confusion over which it means at a particular point, clarification of the context is all that's required. Regardless, it's unimportant to what, exactly, the word "PHP" actually refers; the language PHP, as defined by its specification, is completely independent of the word "PHP", after all. -DavidMcLean?]
Clarification is indeed nice to have, but that's irrelevant to what "Php" refers to for most users of that term. Their perception may or may not be influenced by the existence or lack of any such clarification. It may influence their perception, but still the masses have final say by our societal conventions for terminology (legal issues aside).
[Certainly, just as what "Php" refers to for most users of the term is irrelevant to what PHP is as a language. -DavidMcLean?]
Who or what is the ultimate determiner of is-ness?
[The language design as codified in the specification determines what the language is. We've been over this. -DavidMcLean?]
That is only your opinion, not a proven fact.
[No, that would be only your opinion. A programming language is defined by its design, as codified in the specification. Implementations attempt to meet that specification -- if they fail to meet some criteria, then the implementation is not actually implementing the same language the specification describes. Such an implementation is a perfectly reasonable implementation of some other language, but since it was supposed to implement the language in the specification, it may be called "wrong". That's about the gist. Again. Any questions? -DavidMcLean?]
Sorry, I just don't see any clear, precise logic that leads to that conclusion. I just plain don't. You agreed that most terms in use are defined by usage (the "masses"). However, you seem to think that some IT terms are an exception to the rule. It's completely unclear to me where the rules for such exceptions come from.
[No such exceptions exist. IT terms are irrelevant. I'm concerned not with what the word "PHP" refers to but what the language PHP is. (Along with what other programming languages are, of course.) The word "PHP" can easily refer to PhpLanguage, that language one could laughably claim was designed by Zend, or to some specific implementation of it. The word "JavaScript" can easily refer to EcmaScript as specified by ECMA or to some specific implementation of it (say, V8). Actually, it seems you're presuming that the definition of a word and the definition of the concept it refers to are inextricably tied together as a unit. One can trivially observe that that's not an accurate assumption to make, both by noting that there are many words which can refer to multiple concepts dependent on context and by noting that many words can all refer to the same concept. Whether or not a word actually refers to a language is certainly determined by usage; the components that constitute that language are determined only by design. Is that clearer? -DavidMcLean?]
I have to go Bill C.-like on this and say "is" is relative. It's generally an equivalency statement. I focus on what users of a tool consider something to be. If they are "wrong" in some God-view sense, so be it. If people commonly use chainsaws to scare away crows instead of slicing wood, to THEM it's a "crow-scaring device" despite what the manufacturers intended. What a tool "is" is relative to the user.
[No, "chainsaw" isn't equivalent to "crow-scaring device". You could correctly claim that "a chainsaw may be used as a crow-scaring device", just as you could claim that, say, "a jump instruction may be used as a for loop", but it's absolute sophistry to suggest that a tool being at all capable of fulfilling a particular purpose makes it a tool for that purpose. You can use all sorts of things for unintended purposes; that doesn't inherently imply they're at all suited for the purpose, nor any grand equivalency. Crow-scaring is not what a chainsaw is designed for, nor built for, and indeed it's really quite ill-suited to the purpose, considering you can scare crows with tools that don't require petrol or electricity. -DavidMcLean?]
You are artificially beatifying original intent.
[Perhaps, but no more so than suitability for purpose, which I'm sure you can't deny the importance of. -DavidMcLean?]
We are not measuring importance here.
[Indeed. I didn't say we were. Please try to stay on-topic rather than seizing on individual insignificant details of your correspondents' arguments to disagree with. I claim it unreasonable to claim a tool is for a purpose simply because it is capable of fulfilling that purpose. There are a few factors that can correctly determine whether it's reasonable to claim a tool is for a purpose. The tool's original design intent helps -- this chainsaw was designed to cut down trees, so it's for cutting down trees -- but the real determinator of "tool-is-for-purpose" is whether the tool is suitable for the purpose. Lacking the ability to fulfill the purpose at all harms suitability; having extraneous aspects that do not help fulfill the purpose do too. The fact that a chainsaw must be powered to operate makes it unsuitable for scaring crows, because it is possible to scare crows readily without a power-consuming tool (so the power consumption is extraneous), and since tools that do not require power are preferable for use out in the fields guarding crops, the chainsaw's need for power also weakens its ability to fulfill requirements at all. (Interestingly enough, the intent of the designer is really only relevant insofar as a tool intended to solve problem X, if well-designed, will also be suitable for solving problem X.) -DavidMcLean?]
Unless the SFP is zero, it's generally irrelevant (and possibly still even if zero). Vocab is shaped by actual usage, not engineering or economic perfection/efficiency evaluations. Efficiency is irrelevant as far as I can tell.
[Nonsense. Suitability for purpose is extremely relevant. For example, the notations "1" and "{{}}" both indicate the same integer and are entirely interchangeable. But if you're doing basic arithmetic for some real-world application, surely you'd prefer to write "1 + 2 + 3" instead of "{{}} + {{}, {{}}} + {{}, {{}}, {{{}}}}"? Yet if you're trying to formalise the integers, encoding them as sets is far more helpful than merely assuming the digit notation already applies. You could use either tool for either problem, but one is far more suitable for specific purposes than the other. It's a relevant property. -DavidMcLean?]
I meant relevant to what "programming language X" means. It's true that SFP has an influence on what the masses call what, but that doesn't mean it's a requirement. A lot of things influence their decision, but that does not mean all those factors become the meaning. You seem to be confusing influence with prerequisites.
[You seem to be confusing what people say with what is correct. It's completely unreasonable to say that "{{}} + {{}, {{}}} + {{}, {{}}, {{{}}}}" is an acceptable notation for counting items at a supermarket checkout. The masses could still say it. -DavidMcLean?]
"Reasonable" is not prerequisite to having the ability to change the def. You are over-complicating this. "Quantum leap" is an unreasonable term for "large change", but the masses "installed" the definition anyhow. Go spank them if you wish.
[Oh, I shall. I maintain that (correctly) describing a tool as for a particular purpose demands that it is reasonable and suitable to use that tool for that purpose, however; BrainfuckLanguage can be used to implement any program you like, for instance, and it'd simply be wrong to describe BrainfuckLanguage as a tool for writing Web apps. Back on our main topic, however, I believe we're still arguing at cross-purposes. I do not claim that "PHP", "JavaScript", "Python", and so on unambiguously and consistently refer to the languages PhpLanguage, JavaScript, and PythonLanguage as designed and specified; indeed, those words very often refer instead to the languages' reference implementations, and as with any word in natural language there is no way to ensure that they aren't used to refer to different, perhaps completely unrelated concepts. Rather, I claim that the languages PhpLanguage, JavaScript, and PythonLanguage, as designed and specified, necessarily are only defined by their designers -this means not that someone saying "PHP" always means PhpLanguage, but that someone writing "foreach ($array as $item) {}" in PHP always means a foreach loop, among other things. -DavidMcLean?]
The bottom line is that if the author's written specification and the actual interpreter vary (due to errors or ambiguity), the users tend to favor the interpreter as the reference. If they are my audience, I thus use the interpreter as the final arbiter. That's logical and rational. Any God View of what things "should be" is irrelevant and a distraction. -t
[In the absence of any specification or documentation, you can't use an interpreter as a language reference. If both are available, but there is a conflict in behaviour between the specification and the reference implementation, then it would be appropriate to submit a bug report and ensure that the discrepancy is corrected -- such a bug might be resolved while preserving existing implementation behaviour by modifying the spec, or the implementation might be corrected to implement the same language the spec describes. As a change to the spec creates a new language and any other existing implementations will still be implementing the old language, the latter fix is often preferred. There's no need for a "god view", because if there is a disagreement between the spec and the implementation then they simply define/implement/codify/verb two different languages; one of these languages is preferred over the other for implementers, due to their original intent (to implement the language as designed and specified), but not necessarily for users, except perhaps when trying to guarantee implementation-portable code. -DavidMcLean?]
The last part starting with "they simply" is not clear to me. I can "define" anything I want any way I please, but others may not agree; same with spec writers and implementers. The first part appears to be an off-topic policy suggestion.
[The first part is a statement of fact -- if all you have is an interpreter, and no specification or documentation, then you have absolutely no way to make use of the interpreter. Thus, using an interpreter as "the reference" simply can't work in general. And "they simply define/implement/codify/verb two different languages" means that the specification describes a language A and the implementation implements a language A', which are distinct languages despite having many similarities. You can certainly define anything any way you please, such as by defining a language B which is further distinct from both A and A', but the specification will continue to describe A rather than B and the implementation will continue to implement A' rather than B. -DavidMcLean?]
Fortunately we don't live in a black hole such that we can use the author specs and/or other languages to make decent initial guesses about the implementation. The rest is circular logic or dependent on who is labeling the parts, which gets back to the issue of who is the ultimate authority. The author can call it their "Specification for Programing Language Foo", but the masses don't have to agree to call related results "Foo". The masses can make the author's vocabulary preferences a WalledGarden and/or an ignored garden. They are not forced to accept anything from the author.
[Please, if you're convinced there's circular logic, point it out. Use of the author's spec, or of any documentation at all, means the interpreter isn't "the reference" any more -- at best it's a reference. There is certainly no requirement that the masses accept that the word "Foo" refers to the language defined by the "specification for programming language Foo"; this is trivially true since two entirely different languages could be designed and given the same name, but the language codified by the specification will still be a language, and working with that language will necessarily entail accepting the constructs it defines. Language A is language A regardless of the name it's given. -DavidMcLean?]
"Influence" yes. "be", no. Re: "working with that language will necessarily entail accepting the constructs it defines...". In practice that's usually the case to a large part (not necessarily 100%). But that's NOT the same as final vocab authority. The users often ride the authors' horses when it suits them, but can and do hop off as they please. The "acceptence" you talk about is voluntary.
[I used "be" a few times in that previous bullet point. From your response, it sounds like you're referring to the part where I said that "the language... will still be a language". From that paraphrasing, you may notice how absurd it is to suggest the word "be" doesn't belong. "influence" might also belong -- a language certainly might influence another language -- but why would that mean it isn't a language any more? Acceptance is certainly voluntary -there's no demand that users use a language at all -- but if you do wish to use a particular language, that necessitates first accepting the language, as codified by its specification. You cannot "hop off" the specification without rejecting it and therefore no longer using the language it specifies. -DavidMcLean?]
No, it's not all-or-nothing.
[Except that it in fact is "all-or-nothing". Even if you try to follow some specification for A, mistakenly deviating from it means the language you implement is A' instead of A. If you deliberately deviate, the same applies. -DavidMcLean?]
What is A versus A' is relative. Each person or group can label and/or ignore one or the other any way they damned please.
[Correct, because A and A' are pretty much just variables that refer to languages, and you're allowed to assign whatever you want to a variable in the process of using it to solve or express something (as in maths, where you can say "let x = 5" with no problems). However, that's frankly irrelevant. In my statement above, A and A' are already assigned to particular languages: A refers to "the language codified by a particular specification" and A' to "the language implemented". As the language codified and the language implemented differ, I claim A ≠ A' and therefore that the implementation is not of the same language the specification describes. -DavidMcLean?]
If nobody wants to refer to "the language codified by a particular specification", or uses such interchangeably with an implementation against the spec author's wishes, tough shit. No army is stopping them such that they will continue to do it.
[Correct. I'm not stopping them either. Neither of those things are particularly incorrect or problematic. Of course, in cases where the latter (using the same "variable" or name to refer to both implementation and specification) causes ambiguity, it would be polite to clarify. Nonetheless, it's not a huge issue. -DavidMcLean?]

And my WYSIWYG point still stands: In tag-free languages most or all of the language's operators/API's that "emit" inspect-able content don't hide extra information, unlike tag-based languages such as JS and PHP. A variable that emits "123" will subsequently act the same for further usages, while JS and PHP may not because they have a "hidden" type indicator/tag that is typically not emitted by language's operators/API's. The emitting operators/API's are not showing you the whole picture (and I don't count debuggers etc. per above). -t

[Why cherry-pick? User-facing output formats can hide all manner of information, and not only values' types (e.g., rounding for display hides decimal precision). Development display formats, which typically correspond to literals for producing the values being displayed, do not. Why would the former be a more valid basis for a system of types, variables, and values (or lack thereof) than the latter? -DavidMcLean?]

Like I keep saying, debuggers/consoles can change or disappear without changing the perceived existence of the language. They are an unstable reference point. If you change the language's base operations/functions, you are changing the language itself, to most app programmers. And debuggers/consoles don't necessarily correspond well to literals, per above, such as where literal quote-ness doesn't have to be tracked or kept in some languages.

[A language isn't defined by what "most app programmers" think of it. Languages are defined by specification, and the specifications for popular imperative DynamicallyTyped programming languages describe development output formats (repr() in Python and .inspect in Ruby for example). The consoles for both languages use this facility, but in both cases it's definitely a baked-in core language feature and removal will change the language itself. -DavidMcLean?]

Vocabulary is ultimately defined by "the masses" rather than tool makers whether you want it to be or not. If some languages or implementations blur the distinction between user-side output and "X-ray" tools, that certainly may complicate the matter. Classification can sometimes get messy. Personally I think they should be careful about hard-wiring some things to arbitrary implementation, but no language builder has to take my abstraction advice. (Sometimes companies do such to make it harder to clone a language/tool.)

[Languages are defined by their specifications. If the masses disagree, they're simply wrong. And "implementation"? repr() and .inspect have nothing to do with implementation; they're utilities for producing a literal that denotes a particular value, as defined by the language's syntax and semantics. The underlying implementation is irrelevant, since only conformance to the specification is required for these to operate correctly. (And that wouldn't make it harder to clone such a language, because it's not depending on implementation details.) -DavidMcLean?]

Bullshit! It's generally agreed that usage defines vocabulary. And the last part is circular reasoning.

[Usage defines vocabulary, but a language is not a word. A language is defined by a specification, and disagreeing with that specification makes you wrong, because the specification is the canonical description of the language's behaviour. How is the last part circular reasoning? You suggested that dependence on implementation details would make cloning a language more difficult, so, since I'd just pointed out there's no dependence on implementation details, I also noted that cloning is not inhibited by such. -DavidMcLean?]

A language is defined by whatever hell the language user wants to define it by. The Vocabulary Gestapo is not going to take them away and lock them up (although Russia is getting weird of late). And the "repr()" thing appears to be a side distraction that adds nothing new and so I will not discuss it any further.

[No, a language is defined by its specification. That's why we have specifications. repr() may indeed add nothing new, since it's just one example of the ability to access canonical string representations (or, if you prefer, literals) for particular values; since it's just one example, however, and the functionality is commonplace, dismissing it relative to user-facing output still comes across as unreasonable cherry-picking. -DavidMcLean?]

Defining it by a specification is purely a language user choice.

[Citation needed. -DavidMcLean?]

Citation needed for opposite claim, otherwise the default answer stays at "null".

[Stop ShiftingTheBurdenOfProof. Languages are not discovered fully-formed and studied -- they're defined intrinsically by language designers. The specification is the document that describes the actual language design as chosen by its designers. Use of a specification is, if anyone's choice, a language designer choice. -DavidMcLean?]

Projection. Natural languages are rarely defined by a canon or authority, so why should computer languages be different?

[Because they are. Computer languages are constructed languages, which are designed and defined by an authority. -DavidMcLean?]

Because YOU say so? Lovely. All (known) languages are "constructed". It's not a difference maker.

[No, natural languages aren't constructed. They form organically over time. Computer languages, along with a few human languages which we typically explicitly describe as constructed, were defined and described by an authority. -DavidMcLean?]

So are computer languages. Almost every existing computer language was influenced by one or more prior languages, personal preference, and market success, ie, "organic". Not sure it would make a difference anyhow. Construction technique is a rather arbitrary tie. The tool user usually doesn't care how it was made; by a plant named "Seymore" in Little Shop of Horrors, or by some dude at a drafting table.

[Computer languages were certainly influenced by prior languages and other aspects, but they don't form organically -- they're explicitly designed by an individual or group. Thus they're called "constructed", since, rather than forming over time through use as natural languages do, they're designed and defined explicitly. Thus, the specification is an absolute authority on how the language works. It certainly doesn't matter to a user who wrote the specification; regardless of the language designer's identity, disagreeing with the specification remains incorrect. -DavidMcLean?]

Sorry, I don't see how the second part follows from the first part. Please flesh out your logic steps more. If Vender B comes along and makes a new interpreter with the same IoProfile, app developers could start using the B version and stop caring about A's version and the author of A would be ignored. IoProfile is closer to how the tool users view tool equivalency. You may personally WANT them to care about the original author, perhaps because you are an author yourself, but sorry, that's not the way the market in the USA works. I'm just the messenger.

[Which parts do you believe to be "first" and "second"? Natural languages form through use over time with no explicit effort from a designer; constructed languages are designed up-front and evolve only as a result of explicit design changes. A language designer may write a specification of their language's behaviour; as computer languages are constructed and have exactly-and-only the properties the language designer gives them, that specification is a definitive and canonical description of the language behaviour. Thus, personal disagreement with the specification is fundamentally wrong, since the specification is the canonical definition of every aspect of the language. If vendor B came along and made a new interpreter that conformed to the specification, there would be no difference; an interpreter that did not conform to the spec would, quite simply, not be implementing the same language. An implementation that follows the spec should meet your "IoProfile" requirement but should also meet the stronger requirement of having identical syntax and semantics to other conforming implementations. -DavidMcLean?]

If the spec had an error (deviate from implementation) and lots of source code built up to rely on the error, then the IoProfile would trump the written specification.

[No, it wouldn't. If the spec deviates from the implementation, the implementation is in error. -DavidMcLean?]

It's often the case that hardware emulator builders have to match the implementation bug-for-bug, ignoring documentation even, if they want their emulator to be considered "compatible" in the market. Some games even exploited bugs. THE MARKET ULTIMATELY DOES NOT USE "PERFECTION" OR DOCUMENTATION TO JUDGE COMPATIBILITY.
[It's certainly true that to maintain compatibility with a buggy implementation, a clone must often replicate the same bugs. However, that merely means both implementations are equally flawed, as they do not correctly implement that which is specified. -DavidMcLean?]
But we are measuring compatibility here, not perfection. To users of a Commodore-64, the Commodore-64 is what it is, NOT what it SHOULD BE.
[Are we measuring compatibility? I thought we were arguing over whether a specification or an implementation is the canonical source for a language's description. To maintain compatibility with a broken implementation, a clone might indeed need to deviate from the spec; however, as a result both implementations are not in fact implementing the language as specified and hence both are wrong. -DavidMcLean?]
Sigh. Again, we are measuring compatibility here, not perfection. Perfection is another topic.
[Why are we measuring compatibility? Compatibility can often demand that bugs and flaws be preserved, but it doesn't stop them from being bugs and flaws. -DavidMcLean?]
IN PRACTICE, association of device terms (such as "Commodore 64") is often based on compatibility, not written specification. Compatibility trumps written IN PRACTICE when they deviate.
[Sure, but again that doesn't stop bugs and flaws in reference implementations from being bugs and flaws. The spec is still the canonical source, regardless of whether attention's paid to it. -DavidMcLean?]
There is no canon. You are imagining things that don't exist. Did you forget to take your meds?
[You are imagining away things that exist, such as specifications. Did you take meds you shouldn't have? -DavidMcLean?]
It may exist, but is no canon.
[Except that it is. A specification, as written by a language's designer, is the canonical description of the language and its behaviour. Implementations that do not conform to that spec in every detail are strictly not implementations of that language. -DavidMcLean?]
It's only a canon in YOUR head, but sorry, you are not God, even though you think you are.
[… I don't think that. What the heck are you talking about? Computer languages are designed and defined by their designers, who write specifications to codify that design. Thus, the specification is canonical. How wouldn't it be? -DavidMcLean?]
NO! They are "defined" by how the masses want to define them.
[No, they are defined by their designers. -DavidMcLean?]
Not in our society.
[Yes, in our society. What other societies would I be talking about? -DavidMcLean?]

Languages are defined by usage and perception, not by perfection. I know you are going to disagree. So be it. LetTheReaderDecide.

[Natural languages are. Constructed languages are not. -DavidMcLean?]

Go ahead and believe that.

[I shall, and I'd encourage you to do the same. -DavidMcLean?]

I'm confident most readers will agree that you are full of shit. Shops are free to consider equivalency any damned way they please.

{I find that unlikely. DavidMcLean? is entirely correct, and if you had bothered to learn anything about the subject, you would know that.}
You should learn about the subject by getting out in the field more instead of drooling over idealistic fake authorities in ivory towers. Language users don't give a flying monkey ass about interpreter builder opinions if it gets in the way of their work and peer-to-peer communication.
{I am out in the field. I'm a language user. Nothing about what DavidMcLean? has said gets in the way of our work or our peer-to-peer communication. DavidMcLean? is entirely correct.}
Well, your description of how typical developers think and act varies widely from mine. So rather than keep insulting each other with the likes of "had you bothered to read more..." or "you should get out more...", Let's LetTheReaderDecide how typical developers they see and know determine what they use as a reference point. If you claim you know the answer because you "read more", then BRING IT HERE! Don't hide your grand evidence under a bushel. Cheap slothful BookStop, jerks.
{I've never met a developer (outside of you) who thinks and acts like you claim typical developers do. Maybe I got lucky. Either way, DavidMcLean? is entirely correct. Either way, you are pontificating on a subject you've never bothered to learn, either in the field or in the ivory tower. (And if you knew about logic, you would know that what you call "BookStop"s are completely acceptable.)}
Fine, our experience differs and we'll LetTheReaderDecide who paints a picture that best fits their own shop. BookStops are NOT acceptable for claims that claim to be objective. Anyhow, this sub-topic is NOT about compiler technology, but rather about who accepts what authority. If you have sociology references for such, then cite the fsckers. Compiler books are a Red Herring (and probably biased too because compiler writers probably want to be the authority and will likely claim to be unless prodded otherwise.)
[Actually, a "BookStop" is completely objective. A proof being too long to include directly on the page does not make that proof subjective; how could it? In any case, it doesn't matter "who accepts what authority", at all. Programming languages are defined by an authority -- the language designer -- who remains an authority on the language even if that design is completely ignored by the masses. Of course, typically language implementers do not ignore that authority when they're implementing interpreters and compilers that follow the designer's specification; if they did, they'd simply be implementing a different language (spec describes language A, implementer builds an interpreter that deviates from the spec and therefore implements language A', A ≠ A'). -DavidMcLean?]
If there is such a proof, then describe what the proof shows & measures, and give the page number etc. "Page 763 of Dr. Snoogenhimer's book, 'IT and Cats', proves that tables with more than 42 columns kills all kittens in the building in 32.7 seconds." Is a summary like that so hard? See below about a "different language". You are repeating your replies. I hope your code is not as poorly factored as your replies.
[Providing a page number and summary would be nice, sure, but it doesn't pertain to the issue of objectivity. And yeah, I'm repeating my replies to an extent, because you're scattering your misconceptions all over the page. -DavidMcLean?]
If you think it's only about page numbers, then you missed the point.
[Indeed. That's why I said "[p]roviding a page number and summary would be nice". -DavidMcLean?]

[Then most readers would be mistaken and would do well to comprehend the distinction between natural and constructed language. -DavidMcLean?]

That distinction is arbitrary.

[How so? What do you think it means for something to be arbitrary? Why would a distinction like this one be arbitrary? -DavidMcLean?]

Like you forgot above, shops are free to ignore that factor, and often do.

[How does that make the distinction between natural and constructed language "arbitrary"? How does it even relate to it? -DavidMcLean?]

I'm judging "compatibility" from the tool users' perspective. If you want to judge it from God's perspective, that's fine, but I won't care.

[Why are you even judging compatibility? When did we start doing that, instead of arguing over whether languages are defined by their specifications? -DavidMcLean?]

I can "define" anything I want, and a language author can define anything they want. Making definitions is free and easy. However, if users/masses choose not to use that definition, tough shit, they get the final vote.

[Language designers define the language and codify that in terms of specification. It doesn't matter if the definition is ignored -- that simply implies that the language is ignored. Popular languages, quite obviously, have not been ignored. -DavidMcLean?]

If you want to argue that 95% of the people are using a definition wrong, so be it. Only 5% will care.

[I'm not sure to what precisely you're referring with your imaginary statistics, but it reeks of ArgumentFromPopularity. A spec is still a canonical language definition even if 0% of users pay attention to it. -DavidMcLean?]

Language IS defined by ArgumentFromPopularity. Languages are meant to communicate, and if some or most communicators choose to not recognize or recognize differently some part of the language, they can and do.

[Natural languages are defined by ArgumentFromPopularity. Constructed languages aren't; they're defined by their designers. Stop equivocating. -DavidMcLean?]

No evidence that the rules of vocab are different for both. Stop making up false rules.

[Plenty of evidence. Just read what I've been saying. Constructed languages are those defined rigourously up-front by an explicit designer -- an individual or group specifically setting out to build a language -- and evolve only as a result of deliberate modifications to the language. Natural languages form and evolve simply through use in a community and have no governing body behind them. As the former are guaranteed to meet and only to meet the properties their designers explicitly baked into the definition, the design as planned by the designers and codified in their specification is canonical. -DavidMcLean?]

It's still not clear why or how "rigorously up-front" makes it canonical. Is this kindergarten where you get points merely for trying such that their fastidiousness should be rewarded with canonization? I don't get it.

[Put simply, the design and specification of a constructed language is that language. It can't help but be canonical, by definition. An interpreter might exist that interprets and executes instructions written in that language, but the interpreter isn't the language. If you write an interpreter that doesn't meet a given language's spec, you've not written an interpreter for that language. -DavidMcLean?]

No. The masses that utter "Php" get to define what "Php" means. Maybe that's not fair, but that's the way vocabulary is traditionally and currently defined.

[True enough, but that decision would be over whether "Php" means "the language commonly known as PhpLanguage, created by Zend" or if it means something else entirely. The language being referred to is formalised by specification (To an extent. As usual, PHP's a poorly-documented mess.), and its constructs are defined by its designers rather than by the masses who speak of it. -DavidMcLean?]

"Kleenex" (below) is likewise formalized in legal documents, but the masses choose to ignore that fact.

[Beware of conflating a word's definition with a concept's or more specifically a language's. The words "Kleenex" and "Php" can refer to appropriately-branded facial tissues and languages respectively, or might not, and that's a natural-language question. There is no authority that can assert that "Php" always means PhpLanguage, nor is there a canonical source. I haven't actually been claiming otherwise, however. What I do claim is that PhpLanguage itself, not the word referring to it, is a constructed language and hence has formalised and canonical definition. Whether, for example, the word "for" in PHP indicates a for loop or a function definition is a constructed-language question, which is answered by specification, rather than merely a decision for the masses. -DavidMcLean?]

I will agree that it "has a formal definition", but not that it's canonical. Canonical-ality is about authority. In our society, it's generally agreed that masses are the final authority on definitions technical and non-technical (except maybe in highly regulated professions such as medical and legal). In other words, the existence of a formal definition X is not necessarily the same as acceptance of the definition. Like you ignored above, ANYBODY and their dog can make a definition. But acceptance is a bigger hurdle. (The masses can and often do tentatively agree to follow the author's specification, but are not compelled to do so.)

[Absolutely a canonical definition demands an authority. The definition of a particular language has an authority, that being the language designer -- if you refer to a particular language, assuming you do mean language X when you say X, you necessarily defer to the authority of the language designer. Anyone can make a definition, and if they choose to do so and make a language definition, they are defining a new language. Acceptance is not necessary; the language is defined by its designer's definition, and ignorance of it is simply ignorance of the language. -DavidMcLean?]

You are repeating yourself. I think you just want your profession beatified. Well, too fucking bad, the masses get final say. If that hurts your ego or idealistic view of the world, the hell with it; time for your "pride" or idealism to get a reality check. I'm tired of your bullshit; you are a biased fool.

I personally find your Catholic-like view of IT disgusting and disturbing, bordering on being dangerous to the profession. --top

[Of course I'm repeating myself; you keep being mistaken in exactly the same ways, so I'm repeatedly explaining where you're mistaken and what's correct. The masses do essentially decide the definitions of words in English, but only the language designers get to decide whether "while" indicates a foreach or while loop in PHP. -DavidMcLean?]

Some control is not perfect control. And the masses decide whether to accept the language to begin with.

[Care to illustrate how a language designer's control over the meaning of their language is imperfect? -DavidMcLean?]

See xBase scenario on this page. And the Commodore 64 example where to the market it's defined by its IoProfile instead of what the documentation says.

[The xBase scenario has nothing to do with a language designer's control over the meaning of their language. Care to use an on-topic illustration? -DavidMcLean?]

"Meaning"?

[Yes, meaning. You could also use the word "semantics". I offered an example above: whether the "while" keyword in PHP indicates a foreach loop or a while loop. -DavidMcLean?]

Once it's used for a while, the associated terminology gets kind of "locked in place". However, if there is a discrepancy between "official" documentation and actual language behavior, the behavior usually trumps the doc in terms of what the language users actually consider to be "the language", especially if that difference is entrenched in existing code. If another vendor wants to make a clone, they usually choose to clone the actual behavior, not the originator's documentation.

[How does any of that imply that language designers don't have control over language semantics? "once it's used for a while"? It'd have to be designed into the language before being used at all. If there's a discrepancy between the specification and implementation, again, the implementation is wrong; it's irrelevant what users think of it. -DavidMcLean?]

I agree it may be "wrong", but definitions and conventions are not defined by accuracy, but by human perception, and to most of the humans, compatibility matters more than "accuracy", and thus shapes vocabulary more.

[Definitions in English and other natural languages are defined by perception. Definitions in programming languages are not. We've covered this. -DavidMcLean?]

You keep claiming that but do not prove it.

[I've elaborated already on exactly how it's the case, but, again: Programming languages are constructed, defined intrinsically by an individual or group. The definitions are codified in a language specification, and those definitions are established only by the decisions of the designers. The language only evolves or changes as a result of deliberate design effort -- which will also be codified in the spec -- and not organically as users work with the language. Thus, the language is defined by its specification rather than by how users perceive it. -DavidMcLean?]

You are not clear on how the non-organicness changes who or what gets to define a language. It appear to be a rule you pulled strait from your ass. I guess if your ego grants you to be the IT Pope, whatever you pull out of your ass is an instant canon.

[Very polite. Being organic or constructed is a literal description of who defined the language. An organic language arises through use throughout a population over time, a constructed language is codified by a group of designers through conscious action. By direct implication, the former is defined by the masses and the latter by its designers. -DavidMcLean?]

Nope! As the Kleenex scenario illustrated, even if the term is carefully crafted by expert marketer think-tanks, in the end the masses get to define "Kleenex" to be what they want.

[Again, you're equivocating between natural/organic and constructed language. "Kleenex" is a term in the English language, which is a natural language. Do you have a scenario that's actually from a constructed language to present as a counterpoint? -DavidMcLean?]

You are flat wrong. "Php" is also a term in the English language. When human mouths move to form the sounds for "Php", it's no diff than "Kleenex".

[… so? That doesn't change anything. All that brings into question is whether "Php" refers to PhpLanguage, to Zend's PHP interpreter, or to something else entirely. It's still an example of popularity-based definition in natural language, not constructed language. -DavidMcLean?]

As mentioned above, most developers are referring to implementation and not a written formal spec. And I don't know what you are getting at for the "constructed" issue. We are talking about what "Php" means, which is on par with "Kleenex" or "Commodore 64".

[Ah, that could be the point of contention. We aren't talking about what "Php" means. We're talking about what PhpLanguage (or, more specifically, constructs in that language) mean. PhpLanguage itself is a constructed language, which means its semantics are unambiguous, well-defined, and formalised in the documentation and spec. The word "Php" exists in a natural language (English) and hence is open to question. The elements of PhpLanguage itself exist only in a constructed language and are not. -DavidMcLean?]

The vast majority of language users care about the implementation as it is, not any formal spec. (A thorough spec is probably too dry to serve as a training or reference guide for most anyhow.) That's the perspective I usually look at. If you don't want to look at things from that perspective, it's your prerogative, but nobody may care, except a handful of like-minded beings or perhaps a clone language builder. But if the clone language builder wants success, they should also consider IoProfile.

[Well, to an extent. It's true that users typically work with the implementation rather than with the specification alone. However, the implementation will be of the language as specified by the spec, and understanding of how the language works will be based on the semantics described in the spec rather than the details of the implementation (e.g., things like evaluation stacks are not readily exposed). It's reasonable not to consider the specification directly for most programming, but irrational to deny that it canonically codifies the language's behaviour. -DavidMcLean?]

I guess I'm irrational then. You fuckers seem to be loons to me. If the formal spec is not clear or deviates from implementation, the functional "canon" is the implementation TO MOST LANGUAGE USERS. If they are angering the IT Pope by doing such, it appears the Pope's forces are slow to arrive such that it keeps happening.

[Yes, you're irrational, as well as rude. The language is that which is defined by formal specification. If an implementation deviates, then the implementation is in error, regardless of whether users have to work with the flawed implementation. -DavidMcLean?]

Re: "is that which is defined" to who, and by what authority? Nobody forces language users to recognize the authors as final authority on what constitutes a given language among users. I don't see where your alleged enforcement is coming from. It's 1800's luminiferous aether as far as I can tell. The Catholic church used to enforce so-called canons: one could be booted our jailed for not accepting their canon. There is no equivalent enforcement in the USA today, where it's generally accepted that professionals can accept whatever authority they want (for the vast majority of professions).

[Does the behaviour of language constructs change depending on how the masses view them? Or does it change as a result of conscious effort from language designers and implementers? Languages are designed. Deviation from the design produces a different language. Interpreters and compilers are deliberately built to follow a particular language specification and design, and hence to provide an implementation of that particular language; sometimes they don't succeed, due to bugs or a conscious decision to deviate from the language as specified, in which case the resulting implementation is of a different language to the one designed. There is no need for "enforcement" -- if language A as implemented differs from language B as designed and specified, then trivially A ≠ B, without any need for policing. -DavidMcLean?]

Technically that's probably true, but the masses (languages users) get to ultimately decide what they call "Php" or "Java" or whatnot, as the Commodore 64 scenario demonstrates. If the masses want to call the "broken" version "Php", they can. Neither you nor the ComputerScience Army can stop them. The massed pushed forth the awkward "quantum leap" phrase to mean a "big change", which butchered the original concept behind it, but that's life. The victors write the history and the end-users write the vocabulary. Do the language authors influence vocabulary? Certainly, but that's NOT the same as ultimate control. I do NOT dispute influence.

{Nobody is disputing that the public gets to decide what the terms "PHP" and "Java" refer to. That's true because the terms "PHP" and "Java" are part of a natural language. What you are failing to realize is that neither the term "PHP", nor "Java" are part of the language that those terms refer to. Therefore, using those in the way you are is like trying to counter a claim that apples are red or green by pointing out that this citrus fruit is orange. It's may be true (and in this case it is), but it doesn't matter if it's true or not.}

{On the other hand, the computer languages that the terms "PHP" and "Java" currently refer to cannot be changed simply because the masses want to start using the therm "while" to mean "stop everything at once and exit". The implementation will still treat "while" in exactly the same manner that it did before even if every user starts using "while" when they want to stop everything at once and exit.}

It's not about changing a language, it's about vocabulary. I'm not claiming term usage (directly) changes an interpreter. As far as the While example, see PageAnchor Function001.

{The example I gave is about vocabulary. Notice that the vocabulary didn't change even though all the users of the language started using it as if it had. This objectively shows that the mechanism that is used to change vocabulary in natural languages is different from the one used in computer languages.}

I'm not sure what you are referring to. Please restate.

{I'm referring to the only example I've given. The one referenced in your previous response. The one where the users tried to make a change in the vocabulary of a language by using "while" where they mean "stop everything at once and exit" instead of the usual meaning of while.}

You mean "function"? I don't see that as a realistic example; it's a unicorn on a UFO. When "the masses" accept a language as a de-facto standard, they accept most of it's vocabulary with it. Most of that is not going to change in practice. (The masses still "voted" to accept the initial set.) Thus, in practice the users are not going to change the usage of the base idioms. But here is a variation that is perhaps more practical. Suppose a common Visual Basic-like interpreter inadvertently allowed SUB (subroutines) to return a value if one uses a RETURN statement (of the generic type "object" or "variant"-like thingies):

sub myRoutine(x)

dim foo

foo = x + zoomp(x)

...

return foo // interpreter boo boo

end sub

Language users could end up using it because they are too lazy to rework their intro key-words in their code when they want to change a SUB to a FUNCTION, then start talking about "functions" when referring to sub's, pretty much ignoring the difference between SUB and FUNCTION, and that grew entrenched. Therefore, the user meaning of "function" has changed.

{That's another example of how natural languages change. When the users start using a word differently, in this case "function", the natural language changed with it. Now try that in the other direction. Start with the language where "sub" doesn't allow one to return a value even with a return statement. Try to change it to your variant just by adding return statements to sub. You can enlist help if you want. Let me know when the language changes.}
Sorry, I don't know what you are asking.
[It's a thought experiment. Assume you have a language where functions and subs are distinct, and subs do not return a value. Then try to "blur" the difference between the two, by putting return statements in your subs and generally treating the SUB and FUNCTION keywords as equivalent. Does the language change when you do this? -DavidMcLean?]
I would say "yes", but that's only my perspective as an app coder in that language. The compiler/interpreter responds different than it used to, meaning the overall "language" is slightly different than it was before.
[Did I say the compiler/interpreter responds differently? That wasn't part of the experiment. The only experimental steps I expect you to take are to put return statements in your SUBs and to otherwise treat the SUB and FUNCTION keywords as equivalent. You may also assume your colleagues do the same, if you wish to demonstrate that the masses determine what the language is. -DavidMcLean?]
Do you mean do the experiment as a language user, or as a language/interpreter writer? That's not clear.
[It should be trivially determinable from context, since I asked you to change the way you code with and think about the "SUB" construct in this language, which you only ever need to code with as a language user. So, as a language user, naturally. As yourself. -DavidMcLean?]
I'm sorry, but it appears I'm totally misunderstanding what you are trying to ask. If I put RETURN statements in the SUB blocks in my code I'll probably get syntax errors. Then what?
[Really? You'd get errors if you tried to redefine the "SUB" keyword in this language to mean "function definition" and use it accordingly? It wouldn't just work because languages are defined by the masses? Whatever could that mean? -DavidMcLean?]
I know I'm a bit overweight, but I'm not yet "the masses".
[Sure, that's why I suggested you assume your colleagues are also involved in the experiment -- you could even assume programmers across the world suddenly start using this language's "SUB" keyword as though it worked exactly like "FUNCTION". It doesn't change the fundamentals of the experiment or its result to do so. -DavidMcLean?]
I still don't know what you are trying to say. It appears to be a form of, "Because they are not likely to change the definition under circumstance X means they are not able to change the definition". It would be similar to, "Because the US gov't is not likely to nuke Australia, they are unable to nuke Australia".
[Hardly. Here's a restatement of the intended thought experiment: You have language X, which provides SUB and FUNCTION keywords. The SUB keyword denotes a subroutine definition, which is not permitted to return a value. If you, your colleagues, and programmers across the world decide to treat the SUB keyword as though it works exactly like the FUNCTION keyword -- trying to return a value from it, using it interchangeably with FUNCTION -- what happens? Keep in mind that no changes have been made to the interpreter or language specification. There's no question of probability here. -DavidMcLean?]
This appears to be the same question as above at "[It should be trivially determinable from context,". My answer wouldn't change. Note that it wouldn't change the actual IoProfile, the language user's usual reference source for what the language "is" TO THEM.
{So, regardless of how many users want "SUB" to mean "FUNCTION", they still get a syntax error. That tells us that the computer language hasn't changed in spite of the change in usage. Compare this to your example where a similar shift in how the users used the term "function" did result in a change. Languages that behave like your example are called "natural languages". Languages that behave like my example are called "constructed languages". All current computer languages are constructed languages.}
{So if constructed languages aren't determined by the users, how are they determined? The answer is that somewhere, there is a person (or group of people) that decides that they want "SUB" to never return a value while they want "FUNCTION" to always return a value. That person (people) is the language designer, and they have full control over what "SUB", "FUNCTION", and the other parts of the language mean.}
Again, you are conflating influence with ultimate authority. Your "experiment" is an experiment in probability. If enough users wanted a certain feature bad enough, a different "clone" vendor would likely give it to them. A similar situation bankrupted VisiCalc and propelled Lotus 1-2-3 when VisiCalc wasn't ready for IBM PC's. No loyalty. Also, language users choose to accept given languages/interpreters as de-facto standards to begin with. Users didn't have to accept Php, Java, etc. They were "organically selected" if you will.
{What probability? There's no probability involved at all. Yes, someone could create a new language that added that new feature. If they do so, wouldn't the old language still fail with a syntax error? Of course it would. Furthermore, notice that someone (or someones) had to specify that the new language would be just like the old one except it had this new feature. Compare this to the natural language example you gave. With the natural languages, simply using the terms in the new way was sufficient to change their meaning. With the constructed language, someone (or someones) had to decide that they were going to create a new language that was just like the old one with the exception that "SUB" and "FUNCTION" would now mean the same thing. If no one had decided to do that, the language wouldn't have changed even if every user of the language started using it as if it had.}
But that's from lack of a new alternative implementation, not due to user loyalty to the spec writer. The roadblock to a definition "change" is not what you suggest it is. And technically the masses could still call their new preference anything they want even without a new implementation, such that you are merely making a claim about behavior probabilities.
[It doesn't matter if users are "loyal" to the specification. The specification describes a language A, and the implementation interprets that language A. The masses have tried to redefine parts of language A -- specifically, by treating the "SUB" keyword as though it were the "FUNCTION" keyword. This is rejected with a syntax error, because subs that return a value are not a valid part of language A. Creating a new alternative implementation that allows subs to return values would be creating an implementation of language A', defined as "language A, except that subs are allowed to return values"; even if such an implementation existed, language A would still reject use of "RETURN" inside subs, because language A does not allow subs to return values. Note that there's no preferential treatment of the language spec here: Even if it were possible to provide a language purely as implementation, without any supporting docs, the interpreter would still be interpreting a language A that doesn't accept certain constructs ("RETURN" inside subs) that language A' would. -DavidMcLean?]
Users CAN call anything whatever they want to, including A' as A and vice verse, just as they did to the term "dBASE" outside of Ashton Tate's control. However, ability to change vocabulary is different than ability to change or create implementation. The ability to change implementation is a different matter; please stop conflating the two. I agree implementation and the spec heavily influence terms. My point still stands: Users have final authority over terminology even IF implementation and/or specification writers have a strong influence over terminology IN PRACTICE. Again, strong influence is NOT the same as ultimate authority.
{Why do you keep harping about a point that isn't in dispute? Nobody is saying that the users can't call anything whatever they want. We've explicitly said that they could. That's how things work in natural languages.}
That's how vocabulary works in general. You haven't shown where the alleged exception comes from. Language users could call Php functions "floobs" if they wanted to, and nobody will toss them in jail (next to Galileo). Your examples so far only demonstrate that such is unlikely in many cases. But this is not about probability.
{It doesn't work that way for constructed languages. It's not merely unlikely, it simply doesn't happen. Ever. (Users calling Php functions "floobs" is, once again, an example of a natural language being changed. That isn't in dispute, so why are you still harping about it?)}
Fine, then my reference point is what you call "natural languages", unless I state otherwise. I just don't like your coined term "natural language".
[It's really, really not our coined term. http://wj1.agxhqxwfduj.uk35.e.s48.en.wbprx.com/wiki/Natural_language What do you mean by natural languages being your "reference point"? You can't presume that the properties of natural languages apply to constructed languages simply out of preference for the former; what are you trying to say exactly? -DavidMcLean?]
Let me clarify, I don't like YOUR application of the term. But I'm not going to get into a term fight over "natural language" versus "constructed language" unless you can prove it a pivotal term. My usual reference point will be the language users' vocab perspective regardless of what "kind" of language they are using to refer to computer languages and their parts. I agree a large part of such vocab is typically heavily influenced by the language authors' preferences, but influence is not the same as final say -- at least final to them. Another way of saying this is that any group can (re)define terms any way they please WITHIN that group. There should be no qualms about that particular conclusion, right? As far as whether that is "right", "proper", "rational" on a larger scale OUTSIDE the group is moot, for we are measuring a group's preference, not God's preference nor Spock's preference. Perhaps I suggested that "the masses" determine vocabulary in an absolute/universal sense, but I am now backtracking on that to simplify the discussion. (I'm not changing my mind, just trying to trim what I am defending to finish the debate sooner by focusing on what really matters.) -t
[The distinction between natural and constructed languages is absolutely pivotal. What the word "function" means in English varies wildly depending on context and cannot be enforced to hold a particular meaning -- additionally, there is nothing preventing people from making up words, like "floob". All this is perfectly reasonable, and it's also reasonable to coin working terminology within a group. Critically, however, all of that only applies to natural languages, such as English. In a constructed language, such as PHP itself, nobody is free to redefine terms or invent new ones; only a conscious effort by the language designers and implementers can effect any alteration to the language. This is clearly illustrated by the SUB/FUNCTION thought experiment presented above, where terms defined within the language have fixed meaning and attempts to use such terms for alternative, incompatible meanings is rejected. Preferences are irrelevant -- even if SUBs and FUNCTIONs being distinct is preferred by nobody at all (which is entirely possible, since having separate keywords for such similar concepts is pretty silly), the two terms aren't suddenly going to be unified within the language without conscious intervention from designers and implementers. -DavidMcLean?]
Re: "nobody is free to redefine terms or invent..." Oh? Who got locked up for such? (Beyond copyright disputes). Please clarify your use of "free". Re: "is rejected" By who? Re: "the two terms aren't suddenly going to be unified within the language without..." Terms don't have to change the target nouns they refer to be changed terms. TheMapIsNotTheTerritory. You seem to be making up rules.
[Since for you "free" apparently means free-as-in-not-imprisoned, let's rephrase and avoid the word: In a constructed language, nobody can redefine terms or invent new ones. We've been skirting around it a little, but strictly speaking not even the language designers can actually change a constructed language -- if you introduce or remove some construct in language A, or change a construct's meaning, the resulting language is a distinct A' regardless of who made the modification. In programming languages, this is readily apparent in the differences between versions; CsharpLanguage 4.0 is a different language to C# 3.0, since among other things it has a word and syntactic structure (that surrounding the => lambdas) that the latter does not. Attempts to use terms for alternative, incompatible meanings are rejected by the language's rules, as are implemented in interpreters and compilers; for example, a syntax error can indicate misuse of terms in a language, such as in the SUB/FUNCTION thought experiment. It's true that you don't need to change the concepts to which terms refer in order to change the terms themselves, but I made no claim to the contrary: The terms presented (the SUB and FUNCTION keywords in our thought-experiment language) already refer to distinct concepts, and the experiment suggests attempting to unify the terms such that they refer to the same concept. This, however, is not possible without conscious intervention from language designers and implementers. -DavidMcLean?]
When one writes code, they are "talking" to the machine (at least). Human-to-machine communication is NOT the topic. But if talking to other developers, one is not obligated to use the language's actual terms. For example, OOP "methods" are called "functions" in some languages. But two human developers talking to each other often call them "methods". Developer A and B talking to each can use or create any language that A and B please, and no Computer Science Terminology Inquisition Committee will come to behead them. And language X' may be different than language X, but a group can still call X' "X" if they so please, as the actual dBASE scenario illustrated.
[All that's accurate, but all of it is also irrelevant. When you're talking to other developers, you're typically talking in natural language. When you use "dBASE" to refer to a dBASE clone product, you're talking in natural language. -DavidMcLean?]
I am not following your point. You haven't shown that the natural/constructed dichotomy makes any difference; you only claim it does repeatedly redundantly multiple times repeatedly.
[And then I explain why, repeatedly redundantly multiple times repeatedly. Should I go over what the difference between natural and constructed languages is again? Do you want me to write A ≠ A' again? Should we think though the SUB/FUNCTION thought experiment again? Maybe you just don't want to accept it. -DavidMcLean?]
Both addressed a debunked.
[Pardon?]
{I'm pretty sure he meant, "Both addressed and debunked.", a clear falsehood. Top, where have you shown us that we were wrong about constructed languages? All your "counter-examples" have been natural languages, so they don't count as a debunking. All your rants about users being able to use terms in whatever way they want are, again, about natural languages. They also don't count as a debunking. We are not talking about natural languages. I don't see anything else that might qualify as a debunking.}
ALL languages, both machine or human and organically grown or carefully crafted require both communicating parties to mutually agree on the terms used and neither side, human or machine, has to accept anything from the other side (except in heavily regulated specialties). That seems pretty damned clear to me, but is not sinking in for you guys. I give up. Apparently we are talking past each other. I've grown bored with this topic for now and do not want to try to get to the bottom of it at this time. Another day, maybe.
{Yes, both sides have to agree, but what of it? Nobody has contradicted that. It's how that agreement comes about for computer languages that is under dispute. You keep trying to say that computer languages use the same mechanism to reach agreement that natural languages do. Namely, by the users of the language starting to use the terms in the new way. What we are telling you is that computer languages use a different mechanism, namely the designer of the language declaring what the terms mean. (This designer can be a single person, a committee, or even the ones making the implementation.) The other users have no say except what the designer decides to give them. You can test this for yourself by trying to change a computer language simply by using its terms in new ways. Even if you got everyone to use the terms in the new ways, the implementation still won't accept your new meaning. (This dictatorship of the designer does not prevent the users from using other languages. But if they do, it still doesn't change the language.)}
One has to be careful to separate the ability to change vocabulary on wide scale versus a group, versus changing/forking an implementation versus changing the originators' specification. And further is a distinction between short-term changes versus long-term changes. For example, if group X wanted feature Y and the current implementation didn't supply it, they couldn't suddenly conjure it up, but they could fork/clone or pressure a fork/clone to be produced in the longer run to have feature Y. And if trademark issues don't get in the way, they can call the fork/clone the same as the original one if they so feel. In fact, colloquially they don't have to obey trademark law either; it only "matters" for public publications.
{We have been careful. We even mention that the users could go use a different language if they wanted in the very thing you are responding too. Please be as careful in separating what something is called from the thing itself as you appear to be confusing the two when you start talking about forks/clones.}
It does not seem careful to me; perhaps because some words mean something different in my head than in your head. And the last point seems to assume there is one single proper central reference point (AKA, "God View" or "canon"). I dispute that. Language is relative to perspective/use/intentions/motivations/groups/agreements. Yeah, I know, you probably disagree. When the industry started referring to clones of Ashton-Tate's "dBASE" product as "dBASE" also, I would not call that objectively "wrong" (outside of trademark issues perhaps), nor with the "Kleenex" scenario. It's how the masses chose to name the language category. Arguments can be made for and against such a choice. And even if it was "wrong" by some God View, that may be a side issue; for if you want to communicate with a group, you pretty much need to echo their patterns, even allegedly bad ones. WhenInRome. If you wish to communicate with me using the assumption there is a universal canon, then communication will probably remain difficult because I do not recognize the existence of such an object. You might as well be talking about the Easter Bunny. -t
{Why would you think that it assumes some single proper central reference point? It doesn't assume it, it follows from the type of language in question. It also follows from the type of language that it is not relative to "perspective/use/intentions/motivations/groups/agreements". You can verify this for yourself by trying to change a computer language by changing only those things. You will find that changes to those things do not change languages of this type. Its quite telling that every time you try to show changes relative to "perspective/use/intentions/motivations/groups/agreements" your examples never show a computer language changing, only the natural language used to refer or describe the computer language. In fact, you just did it again. You showed natural language changing not a computer language.}
There seems to be some reference confusion here. If a group decides to call implementation B "Footran" instead of A, which was formally referred to as "Footran", has "Footran" changed? In the minds of Footran users, that answer could be "yes". Their conceptual reference point for the computer language "Footran" is changed, and thus the de-facto implementation "has changed" also, to them (at least). The implementation A is not the automatic or central reference point. Your experiment fails. Thus, in a way it is possible to change something simply by changing what the name references. With physical objects normally such is not acceptable, but with virtual objects there is more leeway. Migrating apps from an old server to a new one is a form of this. The physical box doesn't mean a whole lot to users, and they may not even know the difference. -t
{No, the language implemented by implementation B has not changed, neither has the language implemented by implementation A. Yes, which implementation "Footran" refers to has changed, but that is, once again, a change to a natural language. No, my experiment doesn't fail since you used a mechanism other than changes to "perspective/use/intentions/motivations/groups/agreements". You changed implementations which is none of those things. You probably had to change the code when you migrated it. You weren't careful to separate what something is called from the thing itself.}
There is no objective "thing". It doesn't objectively exist. It only "exists" to more than one person by mutual agreement. Note that I never claimed wishes can bring about ANY system on whim. I only claim what a word references can change on a whim, at least to the word user(s).
{And, once again, that shows a change to a natural language. That natural languages change that way is not under dispute.}
Sorry, I don't know what you are getting at then. Maybe we can agree on this?: Users typically cannot change a specific instance of a specification or implementation. However, they can change which implementation and/or spec they choose to recognize and/or what to call them (at least colloquially).
{Of course we can agree to that. That's (almost) what we've been saying from the start. (What users recognize hasn't been an issue.)}

No, the user interpretation of that particular language feature had changed. The intended nature of that language feature was defined by the language designer, and mis-implemented by the language implementer. The presence of bugs and discovered features does not mean users define the language, it only means they've discovered bugs and unintended features.

Terms are not necessarily defined by original intent. The "bugs" to users often "become" the language, just as the C64 bugs became "features" in the C64 emulators people built. Just to be clear, developers often blur the distinction between "language" and "interpreter", and when they say "language" they usually mean as processed through a given interpreter or set of interpreters. While this may be misleading or ambiguous, it's how developers generally view it. "Language" is essentially overloaded in colloquial-land.

Language is merely a mutual agreement between communicating parties; nothing more, and this includes computer languages. Language may not be, and often is not a perfect representation of reality nor human thoughts. The only thing close to a "canon" in our society is the legal system, especially in terms of trademarks and copyrights. However, the colloquial world is usually free the ignore that, and often does. For example, "Kleenex" is a trade-marked name, but often used in a generic sense. Using it in a small crowd causes no drama, but saying it on TV may get one sued. Legally, "robbed" includes armed confrontation, but colloquially it's often used interchangeably with "burglarized" in which there was no sighting of the thief at all. -t

[Again, you're equivocating between natural and constructed language. A constructed language is more than a mutual agreement; it's formalised and well-defined by its builders. -DavidMcLean?]

Doesn't matter if the masses are free to ignore the builders' wishes, names, or intentions; which they usually are and often do in our society.

[Does matter. The masses are free to ignore everything they want; they'll just be wrong a lot more often if they do. -DavidMcLean?]

As illustrated above, language usage is not dependent on accuracy.

[Again, you're equivocating between natural and constructed language. Your examples are of natural language use. -DavidMcLean?]

I see no evidence they are or should be treated different. And "Kleenex" was quite possibly carefully constructed by a room full of marketers.

[Then you aren't looking. Read everything I've said again. "Kleenex" is an example of a word in natural language and not a counterpoint to my claims. -DavidMcLean?]

"Php" is also "a word in natural language".

[It certainly is. Is that relevant? -DavidMcLean?]

Yes, because you can formalize it until you are blue in the face, and the masses can still choose to ignore that formalization.

Actually the term "dBASE" ran into a relevant situation. Book and software publishers started using "dBASE" to refer to clones of Ashton Tates' original product. Ashton Tate (or whatever they later called themselves) started suing everybody such that the industry collectively switched to using "xBase" instead. Colloquially, many kept using "dBASE" in a generic sense for a while.

[Ah, I think I see where you're confused now. Check the other conversation thread, above. -DavidMcLean?]

Defect is Relative

I've heard cases where defects in hardware design are used to generate interesting special effects in games. The game builder and game users don't consider it a "defect", but rather a feature to be exploited for fun and profit. The game builder and game users don't care what the original engineer's intention was. "Defect" is also relative. One man's shit is another man's fertilizer. In the market, the platform is generally defined by IoProfile. If you ivory tower dwellers want to make up your own cabal definition, go ahead, but the rest of the population will ignore it.

The notion behind IoProfile is usually called a ValidationSuite, and it's used to verify that one language implementation adheres -- in relevant aspects -- to the same specification as another. It's not used for anything else, because it's not of use for anything else. In the "market", platforms are defined by their designers. The proof of this is that no matter how much a user might try, no user can change a language or platform. Indeed, no language user is going to get very far in using a language or platform without the designer's documentation. Noting that, for example, "my new language piffle is Javascript but with the 'function' keyword defined as 'fn'" is eminently useful; in fact, it's the only useful thing -- the implementation would be utterly useless without that crucial bit of specification.

Like I've already said, there are many approximate stand-ins for formally running a "suite", such as running existing shop code. And it's not about changing something it's about defining it. Change of the tool is irrelevant. And most language users do NOT learn from the "official" documentation. Most don't even know where it is. Formal language documentation is often poorly suited for common education or practical reference anyhow. That's why there are so many FooOneOhOneInSevenDaysForDummiesInaNutshellSuperBibleUnleashed books. And if there was a difference between the formal spec and implementation, the FooOneOhOneInSevenDaysForDummiesInaNutshellSuperBibleUnleashed books would more likely document the second (IoProfile) because that's what most readers care about.

"Existing shop code" is no less a ValidationSuite than any commercial ValidationSuite.

It's irrelevant where language users learn a language from; a language is defined by its specification, and all knowledge of a language derives directly or indirectly from that. Imagine a new language was invented and implemented but not documented at all. Imagine there aren't even examples. If users define a language, surely they should be able to figure it out in its entirety given nothing but the compiler or interpreter. No?

Obviously, that's unreasonable. If the language syntax and semantics are unusual, it would be virtually impossible. Extensive experimentation might -- if we're lucky or the language was relatively conventional, and we can be bothered -- reveal some aspects of how it works but we'd never know whether that was the whole of the language or there was more to discover. Therefore, it's not the users that define the language but the language designer who defines -- and documents -- the language. All understanding of the language -- good, bad, accurate or inaccurate -- derives from that. That's true even if the specification is nothing more than "Javascript, but the 'function' keyword is replaced with 'fn'." Of course, in that case it's easy because we're explicitly referring to the specification for Javascript. Similarly, even a language described entirely by undocumented code examples is implicitly referring to the specification of whatever language it most resembles. Otherwise, it would be incomprehensible. Most programming languages share a large proportion of semantics in common, so as long as the syntax of the examples adequately hint at their underlying semantics, it's possible to rely on our understanding of typical language semantics to effectively deduce how a new language works.

Of course, users (and documenters) may invent their own interpretations (which may be dire *cough*PHP manual*cough*) of language semantics, but ultimately an interpretation is only correct if it accurately reflects the mathematical and computational basis for the language. That comes from ComputerScience, which provides the terminology, definitions, concepts, and formalisms that form the basis of all computer languages. Obviously, users can ignore that and create their own PrivateLanguage to describe how they think languages work, but like all PrivateLanguages, it creates a WalledGarden that may initially seem useful -- perhaps to beginners -- but ultimately limits communication and inhibits greater understanding.

Like you keep forgetting, if there is a variance between the publisher/authors' specs and the implementation, the language users and cloners usually use the implementation (IoProfile) as their reference, NOT the authors' documentation. As far as alternative models to "explain" or emulate the IoProfile, we have very different opinions on the utility of those to developer WetWare that are already described in the "value fight" topics that I won't reinvent here in the name of OnceAndOnlyOnce. -t

If there is a variance between some author's specs and an implementation, it gets documented. E.g., someone writes that "it's Javascript, but the 'function' keyword is replaced with 'fn'." Can you show an example where IoProfile is used as a reference? I've never heard of such a thing; I've only seen languages and language attributes documented in terms of syntax and semantics, with sample code often used to illustrate them.

How is the fact that it "gets documented" change anything? I don't see that as relevant. I don't know of a "function"-like example that extreme at this point, but the Commodore-64 example already describes such scenarios. To claim X "C64 compatible", the emulator builders are expected (by the marketplace) to clone the bugs also, which you guys didn't appear to dispute. The documentation for the C64 may indeed change to reflect that expectation. But it doesn't really matter if they change it or not, the public usually uses the actual behavior of the device as their reference point.

The device is specifically defined by its developers, including whatever inadvertent bugs and quirks it may exhibit. How it works in general is defined by engineering and ComputerScience. Its users may believe whatever they like -- from reasonable, say that it was powered by a 6502 processor (it wasn't, it was a 6510, which doesn't matter for most purposes), to unreasonable, like it's powered by ants pulling tiny levers -- but those views are incorrect. What the public believes, rightly or wrongly, is irrelevant. An engineer who wishes to understand the device will not refer to "the public", but to the device itself (every working C64 is a reference implementation of a C64) plus whatever technical documentation is available.

"Incorrect" does not matter. Definitions and "meaning" are defined in the head by the mass of tool users, NOT by God nor ivory tower gurus. I know that seems to bother you, but tough shit!

I don't think the bothered party is me, as I don't appear to be resorting to emotionally-driven vulgarity. Definitions are agreed by convention, and interpretations may be "defined in the head", but what a C64 is, is defined entirely by its designers and developers. No interpretation or terminology has the slightest impact on what a C64 is or does. However, ComputerScience, SoftwareEngineering, electrical engineering and computer engineering provide a common set of conventional terminology and interpretations that are shared throughout these technical fields, thus facilitating communication. Public misuse or misinterpretation of these, should it occur, is irrelevant.

Relevancy is relative. If my target audience is X, I usually write from or for X's perspective. Your Catholic-like view of vocabulary is both stupid and arrogant. The church of the middle ages had a strong physical enforcement policy. Nothing similar exists today. You seem to want a technocracy or "ivorytowerocracy" in place.

Not at all. I'm not talking about what I want in place, but what is in place, and not by any intent but simply by nature. Whilst it's entirely reasonable to target writing at the level of your audience, if you invent a new vocabulary to do so it will almost certainly be ignored. Using the C64 example, you can call integrated circuits "micrits" and I/O "datronics" and the screen a "viduliser" and you might fool a handful of beginners who somehow run across your PrivateLanguage, but the majority of the community will ignore it or laugh at it. Your handful of beginners will soon learn that your PrivateLanguage is unique to you, and will correct their usage.

Right, because like you keep forgetting, language is a mutual agreement between communicating parties. No party is obligated to accept all or parts of the others' language. The actual reasons for why groups accept or deny or alter terms (within their group at least) is complex and varied. And, we may never know the reason for many choices. But the causes (decision influences) are a side-issue.
Natural language evolves by mutual agreement (except for natural language subject to regulation -- see http://en.wikipedia.org/wiki/List_of_language_regulators), but technical language tends to filter down from its origins. Aside from purely colloquial references (like your xBase example) that serve a practical purpose, terminology used in ComputerScience, SoftwareEngineering, and engineering, sciences, technical subjects in general, harks back to its originators, inventors, and primary texts. The terminology used for the RelationalModel, for example, comes from Codd's original paper. The terminology used for SQL databases comes from Oracle and IBM's early SQL products, and so on. Attempts to change this -- like the fellow I know who demanded that the RelationalModel research community stop using the terms "tuple" and "row" in favour of "record" -- garner some casual ridicule and then are completely ignored. As humans, it seems our linguistic inclinations favour ease, and it appears to be easiest to adopt existing terminology because that requires the least effort and makes for the easiest communication with the maximum number of people.
See below.

General technical terminology is defined by the fields of ComputerScience, SoftwareEngineering, electrical engineering and computer engineering; specific "official" terminology is defined by the designers and developers of the C64, and informal or colloquial terminology evolves organically in user and technical communities. All of that terminology is what beginners read or are taught when learning the subject. Of course, once they are no longer beginners, they use the technical terminology that is defined by the fields of ComputerScience, SoftwareEngineering, electrical engineering and computer engineering if they expect to communicate with communities in those fields.

Bullshit. Insist and claim it repeatedly 99 times and it's still wrong. Repetition worked when getting a cookie from your mom, but I am not your mom. Those entities heavily influence IT terms, true, but that's not the same as being an ultimate authority. Anyhow, I going to stop focusing on "ultimate authority" and focus on communicating with the target audience, typically regular developers. Target audience X determines what terms X accepts and denies, and nobody's army will stop them (at least in the USA, unless they mistake it for WMD tech). If you claim they are "wrong" from some kind of Catholic-like University God View, so fucking what. I don't give a flying shit and they probably don't either. Let the Ivory Tower God send us all to Ivory Hell AFTER we die, but here on Earth as mortals, the groups use whatever fucking terms they want.

Is your vulgarity necessary? At the very least, it diminishes the credibility of your argument.

Without force or serious threats, groups can use whatever language or terms they please. Your university has no teeth to stop them. You are paper tigers.

No one is claiming that universities (or anything else, other than the natural language regulators I mentioned above) are attempting to regulate terminology. Universities couldn't care less -- they've got better things to do. I've described what occurs naturally and organically. It's true that groups can use whatever language or terms they please, but in technical fields, the language or terms that groups are pleased to use turn out to be those that come from the definitive sources of the technology and theory that they use. It's easiest that way, because they don't have to go to the effort of constructing new terminology, and it naturally maximises the chances of successful communication if everyone uses the same terminology.

In general I agree in terms of influence, but still the ultimate authority is within the groups doing the communicating. Like I said before, it's often convenient to ride the language authors' horses, but a group can hop off any time they want. (Note the academics don't always agree with each other.)

What you're really talking about are frames of reference. For example, "relation" as used by the RelationalModel research community has a different meaning from "relation" used by mathematicians. They're both using the correct term correctly, but their frames of reference are different. Mathematicians who work in the RelationalModel research community disambiguate by context, i.e., they explicitly identify the frame of reference. Another example is the use of the terms "centrifugal force" and "centripetal force" -- both are manifestations of the same "force" -- but the former is colloquially used far more often than the latter. That usage is usually incorrect, but in informal discussions it's generally known what is meant. Correct usage is dependent upon frame of reference, and engineering work is careful to use the correct term in the correct context.

So, indeed, groups may create variant usage, but that's when their frames of reference are different from the original. However, as usual, their variant terminology is conveniently derived from published academic and engineering origins rather than being evolved or constructed.

In every case, what is considered "correct" terminology harks back to originating academic and engineering papers and texts, not colloquial usage, even when the originating academic and engineering papers and texts derive their terminology from colloquial sources. For example, the term "normalization" was apparently chosen by TedCodd after hearing a political speech that referred to "normalizing relations" with China. There have been ample opportunity for groups to choose alternatives to "normalization" since then, but it doesn't appear that any have. Or, if they have, their use of alternative terminology hasn't caught on enough for us to have heard of it.

Of course it's true that academics don't always agree with each other. Humans in general don't always agree with each other, and this page is proof. I'm not sure how that's relevant here.

Again, I do NOT dispute that academics heavily influences the vocab of many IT tools. That's not the point of contention.

Then what is the point of contention?

Frankly, I don't frikken know. There is a communication logjam somewhere.

Not necessarily. It could be that you agree with me, but the sensation is so unfamiliar that you're sure there must be something wrong.

Indeed. It's uncharted territory. It's like unscrewing parts in the yin and yang machine. It might put an eye out.