Value Existence Proof

From TypesAndAssociations.

This TOPIC IS FULL, triggering a Perl memory error. Use ValueExistenceProofTwo for additions.

Abbreviations Used Within:

LIAS = "Like I already stated"

This is a multiple-choice exam. Please answer all questions.

Question 1: In a statically-typed language, a variable contains or stores a __________ which can be changed by assignment.

(a) Variable (b) Type (c) Value (d) Anonymous variable (e) Tag (f) None of the above

Question 2: The result of evaluating the expression 7 + b * 3 is a _________.

(a) Anonymous variable (b) Value (c) Variable (d) Type (e) Tag (f) None of the above

Question 3: The literals 245, "403", 24.04, and -15 are all examples of _________.

(a) Values (b) Variables (c) Types (d) Tags (e) Anonymous variables (f) None of the above

Question 4: In the statement a = foo(), function foo() returns a _____________.

(a) Tag (b) Type (c) Anonymous variable (d) Value (e) Variable (f) None of the above

Answers are on the other side of this page.

I just see a coffee stain.

Look under it.

It's caffeinated turtles all the way down.

Yes, and the answers are under the turtles.

You don't want to know what's under the turtles. Trust me.

Completed exam paper from Subject T:

Assessors feedback:

Since you refuse to answer Question 1, I shall provide a supplementary question:

Question 1b: In a dynamically-typed language, a variable contains or stores a __________ which can be changed by assignment.

(a) Variable (b) Type (c) Value (d) Anonymous variable (e) None of the above

I don't know what "in colloquial-speak" means, but it seems you do acknowledge the existence of values. That's good, because the entirety of computing and mathematics is dependent on them.

Your response to Question 3 is incorrect, but rather than mark you down, I shall give you an opportunity to answer another supplementary question:

Question 3b: A literal is a character sequence that represents a __________.

(a) Value (b) Variable (c) Type (d) Tag (e) Anonymous variable (f) None of the above

For extra marks, an essay question: Can you explain why you included "(d) Type" in your answer to Question 2, and "(b) Type" in your answer to Question 4?

By some accounts, they contain a "type" indicator (tag).

Good. So for every answer, you've indicated that there are values. Yes?

Yes. I just model them separate or distinct from the "type" indicator, and this is not necessarily different from common usage among developers.

But your answer to question 4 indicated that type and value are returned by foo(). How would they be returned separately?

I model them as a data-structure-like element with 3 parts: "name", "tag", and "value".

Returned values have names? What languages have values with names in their function return values?

In my model, they have internal names (not accessible to the programmer, at least under non-debug modes). I've seen interpreters that do such, by the way. One can even see the dummy/hidden internal names in debugging modes/commands, which is handy because it provides an addressable reference. They may use say a dollar sign prefix because that's not a valid variable name in the regular language such that there's never an accidental overlap. It's a handy modelling and model analysis technique. Most interpreters probably avoid that approach because it's a lot of overhead. But interpreters are designed for machine efficiency, not for human analysis and modelling of the internals.

Hidden names! I thought you were defining a model, not an implementation. Surely something that's hidden has no purpose in a model.

Of course models have hidden/internal parts. And "model" and "implementation" are often interchangeable. For example, God could implement planet movement with hidden epicycles, and we'd never know the difference if done well. We could make an entire runnable interpreter using the tag model, but that would be overkill for the stated goals/purpose.

Models don't have hidden parts, otherwise we couldn't see them in the model. A model may represent parts that are hidden in the real world, but they must be exposed in the model or they're not in the model.

Perhaps there's confusion over the scope of "hidden". I meant hidden to the language user, not the model user. "Internal" is probably a better word.

Can you claim that dynamically-typed languages in general have hidden names associated with return values, or is that an implementation detail in some languages? (Personally, I've never seen a named return value in any language, but I suppose there's always a first time...)

"Have"? It's a model. It's a UsefulLie. Whether such actually "exists" in "reality" (however defined in software-land) is another question that may likely not matter for stated purposes/goals. Remember my epicycle analogy? If epicycles predict planet movements and have other nice properties, then using epicycles for such is not a problem even they may not mirror the underlying "guts" of reality. Watches with calendars don't use models of gravity/momentum either, I would note. The watches use a "fake" model and nobody complains (except maybe for anal drunk grouchy astronomers). I expected you would have anticipates this response from me by now.

A model serves a predictive or illustrative purpose by mapping parts of the model to parts of the real world. What part of the "real world" -- and by that I mean real languages -- are illustrated by "hidden names" in function return values?

Re: "A model serves a predictive or illustrative purpose by mapping parts of the model to parts of the real world" -- Bullshit. It's not required of ALL parts. The watch example illustrates this. (We often have to limit/define what aspect of reality we are modelling, however.)

A model that doesn't map parts of the model to the real world isn't a model. It's a toy, or something else. However, it's certainly reasonable for there to be internal parts of the model that are not directly mapped to the real world, but that are indirectly mapped to the real world. Gears in an orrery come to mind -- there are no gears in space, but they allow the model planetary orbits to be mapped to those in the real world. Thus, the model's gears are necessary; they make the model work. I fail to see how "hidden names" in function return values are necessary -- or even useful -- to make the model work.

I don't know how to explain their utility to you. I'm at a loss to communicate that information to you at this point. Needless to say, the model forecasts accurately with the existence of hidden names. Thus, their worse sin is that they add unnecessary hidden parts (if your claim is accurate) NOT that they break the model's forecasting ability. Thus, "unnecessary gears but not gears that ruin the model's goal".

So, to a model that you've alleged all along is simpler than the conventional explanations -- indeed, that is its main (sole?) reason for existing, it appears -- you add arbitrary and unnecessary complexity? Why not add a fishing reel, a pair of sunglasses and a remote control to your model as well? They'd be just as useful as your function return value "hidden names".

YOU claim it's unnecessary. I don't see that myself.

Please demonstrate its utility, then.

I'm working on that in TopsTagModelTwo.

Re: "because no operation on R [variable] needs to make reference to any T [type]" -- what is getType($x) doing in Php then in your model? -t

{Looking at the type of the value of course.}

Same thing. Just because one has to open an extra door to get to something does not mean it's not being used/referenced. Existence of middle-man doesn't cancel "reference".

{Doesn't mean it is either.}

The getType($x) invocation certainly doesn't need to make reference to any supposed component of variable $x, nor does it need to indirectly find out the supposed type of the value in $x via $x. Given an invocation like getType($x), the interpreter fist retrieves the value from $x and then calls getType() with that value passed in as an argument. The getType() function doesn't know whether that argument came from a single variable, an expression, or some other function invocation. All it receives is a value, and it retrieves and returns the name of that value's type.

That "behavior" is specific to YOUR model, and not a universal truth (based on experimenting with I/O).

It's behaviour specific to MY model, and the implementation of every popular imperative programming language.

For the millionth time, mirroring actual implementation is low my priority list per stated goals and rational. I'm not going to re-re-re-re-argue that fucking point yet again. Arrrrrrg!!!!!

If your model is genuinely simpler than actual implementations, your priorities might have some merit. As it stands, there's no evidence that your model is simpler. Furthermore, because it deviates from actual implementations, you should provide a logical proof that it's equivalent to implementations. Otherwise, how do we know your model is valid?

It's simpler for the heavily-used-parts of my model. The equivalent XML is less characters if you want an objective metric. It's common practice and economically rational to simplify the most commonly used features even if that may complicate some less-commonly-used usages to some degree.

But your explanations are consistently more convoluted, due to the odd conflation of values and variables. Look at TopsTagModelTwo. What's all that code for? For the parts you appear to be modelling, they're more complex than some interpreter internals I've written.

No, they are not. The non-nested XML representations of variables in it objectively have fewer levels and fewer characters, and those are the most common structure(s) being used for the model/kit. I'll agree the explanation of "intermediate values" (or whatever one calls them) would be more complicated, but that's NOT where the majority of thinking and sub-modelling effort and eyeball work will be. I see no reason to complicate 95% in order to simplify 5% here.

The non-nested XML representation has "fewer levels" only because you've chosen to use XML in the first place. That doesn't mean it's conceptually simpler. Your "intermediate" values are indeed more complicated, but as they'll need to show up almost everywhere in even trivial programming, I'm not clear how you justify the claim that it's "NOT where the majority of thinking and sub-modelling effort and eyeball work will be."

XML is what the model user works with. They don't work with whatever notions are in your particular head. If you wish to select a better data structure representation technique (for the purpose at hand), be my guest. And intermediate "values" will NOT show up "everywhere". Your statement is false, or at least misleading. The structure is optimized for this model, not your dinner party or whatever. Embedded "values" are UNcommon in this model. (They are intentionally de-embbed to make them easier to analyze and reference.) If you don't "get" the model, I don't know what else to do at this point. Let the reader choose which model they prefer; you are not the Model Police.

XML isn't a data structure. It's a markup language. The data structure in your model is a tuple. There are better notations for representing a tuple than XML.

That are readily familiar? Or do they have to spend $30,000 to take your courses? (Note I called it a "data structure representation technique", not "data structure".)

Of course they're readily familiar. One of them is used above and you seemingly understood it with no apparent difficulty. I don't know any notation that requires $30,000 worth of courses to understand. A notation is merely a system of symbols used to represent something. The "something" might be difficult to understand -- quantum physics, for example -- and might benefit from $30,000 worth of education, but a notation is trivial.

Your A=B(C,D)-like syntax doesn't have "slots" for actual values/content of the model snippets and "run through" examples. If you added slots, it would look enough like XML that one might as well use XML to avoid the confusion of a PrivateLanguage. It doesn't offer anything objectively new or better over XML. I wish to leverage existing knowledge and representation tools to make the model easier to digest for typical developers.

{What do you think the A, B, C, and D are? Those are the "slots". I'm surprised you even had to ask. The notation appears in early grade school, and has been in use for hundreds of years.}

Not for data-structure-like things. They are not "variables" in the math sense, but "slots" for data, and are used differently. Anyhow, keyword-based structures are more descriptive than positional for "thin" tuples. In examples and pseudo-code, it's easier (more familiar) to reference the parts of XML than positional tuples. Positional only has a documentation advantage when it grows into a table size/shape and we wish to compare "rows". I don't want to invent and describe a new "data description" notation if it gains no notable advantage (nor use an obscure existing one).

Hmmmm, I suppose for bigger examples we could use tables: 

  varName  typeTag  Value
  ------------------------------
  foo      String   My Pet Goat
  bar      Number   99.95
  isOn     Boolean  False
  book     String   Types for Complete Brain-Dead Morons
{They've been used for data-structures for as long as we've had data-structures. In addition, they are variables in the mathematical sense (instead of variables in the computer science sense). (And the fact that you recognized them as variables even though I didn't tell you that indicates that you knew they were in spite of your protests.) Usually one would use the name of the variable to reference it. E.g. we'd use "A" to reference A. I also find it telling that you use the excuse "I don't want to invent and describe a new 'data description' notation..." as an argument for inventing a new data description notation in favor of using an established one.}

What's "established"? You mean academia, or the real world?

The real world. Simple algebraic notations -- like that used above -- have been taught to every school-age child since the 1800s. XML hasn't.

It's used to represent formulas, NOT data-structures/containers. If you don't like XML, I don't care. Whine all you want about it and cry like a little girl; I don't fucking care.

Really? What does <var name="..."><value type="..." repr="..."/></var> show that R=(V), V=(P,T) doesn't?

For one, nobody knows what the second one is without explanation. What the hell is the comma, for example: that's not common notation. The XML is quicker to recognize and relate to for most programmers because it's part of their work. Second, XML allows one to show "values" (attribute content) next to the name. That's easier to read than the values being assigned to letters because one doesn't have to do a back-and-forth mental plug-in step of the value to the letters. (Although WetWare may vary.) The formula style is better if one is transforming the formula, which is why it's used in school. However, we are not transforming here, at least not as part of normal usage of the model/kit.

The comma is just a comma, same as in English. It delimits items and/or clauses. What makes you think "XML is quicker to recognize and relate to for most programmers because it's part of their work"? We're talking about programmers who have difficulty with the PHP manual and its ilk. They're probably having just as much difficulty with XML.

Why fuss about that? Does XML really bother you that much? My judgement is that XML is better for this purpose. If you disagree, so be it. You are welcome to also show your ivory-tower-ized version of the XML (in a separate area) if you wish.

I have a problem with XML if it leads to bizarre notions like avoiding "nesting", with the result that variables and values are obscured and altered in your model such that they differ significantly -- yet pointlessly -- from popular imperative programming language semantics.

This "semantics" thing is in YOUR head and I am not trying to model your particular head. I've demonstrated multiple times that "value" is used in vague ways in practice. You even did so yourself when you suggested output displays "values", which lacks the "T" (type) part of your data structure representation. Quote from you: "I/O doesn't have values? What does output like 123 or "fish" represent if not a numeric value or a string value?" The "T" is nowhere to be found in the output; only the P comes through. (Actually, a better description would be that the output is a translation of the contents of values/variables through output interfaces/operators (such as Print statements) rather than a direct copy of their contents. In some cases it may be a direct copy of bytes, but that's not universal.)

{Correction. You've claimed multiple times that "value" is used in vague ways in practice. You've never actually demonstrated it. That also applies to "type", "have", "do", etc. (I should also note that you just used "value" to describe your view.)}

Indeed. Literals are the output -- hence the lack of a "T" part -- but literals represent values.

"Represents" happens in the head. The interpreter is done with stuff at that point such that it doesn't have to be in the model.

"Represents" is a physical aspect of interpreters and compilers. Each literal -- a sequence of characters -- is parsed, its type inferred, the literal is converted to a representation, and the combination of the representation and inferred type becomes a value. That's what a value is.

So you claim. I want a universal proof, not a model-specific claim. In colloquial-land, "value" is overloaded or ambiguous.

What do variables store? What do literals represent? What do expressions evaluate to? What do operators return?

These questions are not model-specific; they refer to elements of all popular imperative programming languages. How do you answer the questions without reference to values?

No they are not; at least not in a consistent way.

No, what are not? What does "they" refer to? My questions? The elements of popular imperative programming languages? Values? Variables, literals, expressions and/or operators?

But those are used/notion-ized in different ways by different speakers. There is no objective rigor except in a given semi-arbitrary model.

What does "those" refer to?

Those words.

This is a Wiki, so aside from the occasional link to a picture, it's all words. Which words were you referring to?

Values, variables, literals, expressions, operators, types, etc.

This brings us back to the point we were, several paragraphs up. These are the familiar elements of popular imperative programming languages, using terminology recognised by every beginning programmer. How can you avoid making reference to them? Alternatively, if you do avoid making reference to them, how do you ensure that the elements of your model are recognisable to beginning programmers?

Yes, but the vague and overlapping nature of those words requires various compromises, as described below. It's all about weighing tradeoffs. If I use "value" for part X of my model, I shouldn't also use it for part Y to avoid confusion, for example. You seem to obsess on narrow factors rather than back up and evaluate the whole forest.

Note that the descriptions at the top of TypeSystemCategoriesInImperativeLanguages employ those terms without "overlap", vagueness, or ambiguity.

In TypesAndAssociations, I took some of your text from the above and dissected it word for word. After a long discussion, you came to the following semi-conclusion:

That appears to be an admission that your write-up, as it is, is not rigorous. Now you appear to be back-tracking on that. As it is, it's not long and dense. (Difficult, yes, but all your writing is like that to me.) Words like "has", "in", "represents", "contains", "references", "associated", etc. can have multiple reasonable interpretations.

I'm not "back-tracking" on that at all. Whilst the English descriptions unquestionably have no overlap, vagueness, or ambiguity assuming standard English interpretations, I do recognise the potential for misinterpretation that can result with any English description. Hence, in order to avoid misinterpretation of "has", "in", etc., I have provided a more formal treatment at the bottom of TypeSystemCategoriesInImperativeLanguages.

Part of a possible solution is to represent the stateful parts in commonly-used data-containing and/or data-representation languages, such as XML or relational tables (as established thru SQL). Then "has", "in", "contains", etc. are more concrete. We can then define terms like "has" in terms of that representation system such that NOW they would mean something precise and commonly inspectable instead of some fuzzy non-sharable hidden head notion.

Considering the only stateful part of your model is the change of value in a variable, use of XML in some imperative model is at best overkill, and at worst outright misleading. TopsTagModelTwo appears to be an excellent (albeit incomplete) demonstration of exactly how it can go wrong.

I'll deal with any alleged flaws in that topic, when they are pointed out.

Fair enough. Please feel free to correct the flaws.

Please put any comments in TopsTagModelTwoDiscussion. 

   Address 1200 Value F3F4
   Address 1204 Value 0000
   Address 1208 Value A9A9
   Address 120C Value C604
   Address 1210 Value C3B2
It all boils down to that at execution time.

Yeah, but that's not what a programmer typically sees and cares about. They see I/O, including source code.

I wonder what you are trying to say. Anyway the reason I put in the indisputable demonstration of the existence of what we know as a value is that I cannot for the life of me see what you wish to achieve with this discussion. I have only ever had to think about values when using the pointers so commonly used in CeeLanguage. Is this a value or is it a pointer to a value? And that question is nearly always resolved instantly.

{It proves values exist.}

I never disputed that, as a general rough notion. You should have known that. Words and meanings are in the head. If enough heads generally agree that a word means something similar, then it's safe to say it's a "commonly understood concept". HOWEVER, that by itself does not mean it's clear nor objective.

When we try to gel our models with "common usage", we tend to run into sticky choices such that if we use a given word for one purpose then we cannot use it for another similar-looking purpose (if we want a clear model). The side effect of such choices is awkward parts of both our models, such as "anonymous variable" (AV) in my model and "representation" in yours. The difference is that a user of my model doesn't have to see/use AV very often; it's mostly a side note. But in yours, "representation" would be used and seen all the time. I weigh tradeoffs such as frequency of use, simplicity, similarity to existing usage, etc. and feel that I've made a rational balance between such, knowing there is no free lunch. I don't see the rational reasoning in your approach so far, but rather what seems like an insistence that "that's the way it's supposed to be", as if quoting the Language Scriptures. My assumptions about programmer WetWare may indeed be wrong, but at least I state my working assumptions and show how my tradeoff decisions reflect those assumptions.

{Common usage does not necessarily suffer from the ambiguities you claim. Note that the descriptions at the top of TypeSystemCategoriesInImperativeLanguages employ "common usage" without ambiguity.}

See above near the TypesAndAssociations quote.

This and its associated pages is a particularly unsatisfying discussion. Maybe we could have a page called WhatTopWants? and restrict it to that page.

I want a model of types that is not full of shit and vagueness. The detached academics have controlled the type dialog for too long, and it's time to put some hot pepper sauce down their tenured panties to get them off their rusting chairs. Their wallet depends on future programmers coming to their expensive classes to learn types the hard way. They have a negative financial incentive to simplify type-related training. Their wallets stay fatter if students have to learn the hard way and thus they are biased to keep the old way in place. Money rots objectivity.

Please. Not a page called WhatTopDoesntWant?.

{Speaking as one of the detached academics, I should point out that understanding TypeSystem behaviour is an important part of first year for beginning programmers. The vast majority find it trivial and we quickly move on to more challenging and interesting topics. A few very weak beginners get lost trying to understand values, variables and types, but they're invariably so weak overall that lack of TypeSystem understanding is merely a tiny fragment of an overall picture of misunderstanding. They have as much difficulty with arrays, functions, loops, proper style and formatting, using command line interfaces, using GUIs, using IDEs, and so on. Odd models based on peculiar terminology are unlikely to be of any help, especially if said terminology is to be found nowhere else. By the way, I've never met an academic whose incentive was financial. There are far, far, far better ways to make money if that's the goal. Invariably, at an undergraduate level, our motivation is solely to share our skills and knowledge in a subject that we find utterly absorbing and compelling.}

Like I've said many times repeatedly in multiple places redundantly, programmers perform "good enough" with types using vague notions and pattern learning (experience). They don't need a concrete model to use them in a good-enough way. Most the programmers I know don't have any concrete models, just rules of thumb based on experience of what works and what doesn't. You talk to students, I talk to those in the actual field. Plus, most academic settings tend to focus on static languages, where type-ness is more predictable and rigid.

{You're inaccurate in at least two assertions, but that's immaterial. I can appreciate that you want to help weak programmers understand TypeSystems in DynamicallyTyped programming languages. I think your model is likely to cause more confusion than it cures, and it does weak programmers a disservice by teaching terminology they won't see anywhere else. You'd do far better to use your experience with weak programmers to develop a nice set of colourful illustrations, perhaps with cute jokes. Kind of like "Head First Java", but covering TypeSystems.}

They are not "weak", they are average, and sometimes above average[1]. But the academic-style descriptions of languages re types are often difficult to digest for some. If you prove the academic models are the only proper universal truth, then you may have a point (although a UsefulLie can still be a substitute). But so far they appear arbitrary, at least outside of implementation speed. You are a model bigot. DIFFERENT MODELS FIT DIFFERENT HEADS BETTER. You seem to be unwilling to accept that fact that your model is arbitrary, like a programmer who doesn't want to change languages because they are so familiar with the existing one.

{The "model" I've presented is simply how popular imperative programming languages are implemented. As such, it's certainly not arbitrary, because it reflects language reality. It's not a matter of being a "model bigot"; it's a matter of rejecting a "UsefulLie" when it appears there's no reasonable justification for a "UsefulLie". It's a matter of rejecting a "UsefulLie" because it doesn't appear to be useful. That means it's just a lie. If your "tag model" made understanding TypeSystems dramatically simpler and obviously easier, then the UsefulLie might be justified. It doesn't, so it isn't.}

A typical developer usually does not care about implementation. I've already stated my goals, their rank, and the reasoning behind the ranks, including why actual implementation is of low importance compared to other factors. As far as the utility of the tag model, your assessment of it as a UsefulLie is your personal conjecture based on your personal observations. That is not more powerful evidence than my personal conjecture based on my personal observations. In fact, my career path seems to have put me closer to actual developers in the field than you. You look down on them unless they attend your expensive classes. I try to help them, not punish them for not fitting my ideal. Further, you financially benefit from them learning your model, but it doesn't change my wallet either way. Thus, I can claim less potential financial bias. (I'm not claiming bias is actually happening, only that there's a conflict of interest in model recommendations.) If a reader doesn't want to use model X, they don't have to. Give them choice. You have not been elected Model Sheriff.

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

Your "Representation" is awkward also. There is no free lunch, like I described earlier, because colloquial usage is overloaded. The issue is where one takes the punches when terms are de-overloaded for a formal model. I take the punch in the ass where nobody sees it (but my doctor) and you take it on the face where everybody sees it.

{"Representation" makes it easy to explain low-level operators like +, -, is_numeric() in PHP, etc.}

In the second allegation, I believe most would agree that your model's variables "have" types. Something being nested rarely de-has-ifies nouns in the real world, so why should things be diff in your description? Your usage/interpretation of "has" is unnatural.

{Working through examples of expression and statement evaluation, most would quickly discover that there is never a reference to a variable's type, regardless how "variable's type" is determined. If variables have an explicit "type" property, it will never be used. If a "variable's type" can be determined transitively, it will never be used. Therefore, there's no reason for variables to "have" types, and certainly no reason to model it.}

It does depend on the language; each language/operator can do it different. Some look at the tag, some parse. The only way to know for sure is empirical testing. Possibly related: SignaturesAndSoftPolymorphism. -t

{In every popular imperative DynamicallyTyped programming language, it is strictly values to which the interpreter will "look at the tag" -- i.e., examine the type reference property of the value -- or "parse" its representation. I know of no popular imperative DynamicallyTyped programming language in which variables have a "type" property. All popular imperative DynamicallyTyped programming languages have variables without a "type" property and values with a "type" property.}

Values have not been proven to objectively exist outside of specific models.

{Considering they're fundamental to applied ComputerScience and VonNeumannArchitecture, I don't think we have to prove the obvious: They exist in every imperative programming language that has functions, variables, expressions, literals and types. That is what we're modelling, isn't it?}

So you claim. And most the items you mention objectively exist in the grammar of a language. Values don't. See PageAnchor literal_compare_2.

{Grammar is only one aspect of a language. Semantics are equally fundamental. Without semantics, in most languages you can compose an infinite number of syntactically-correct but un-runnable programs, which proves that semantics are fundamental. Note that every (useful) imperative programming language has I/O. Where does I/O objectively exist in the grammar of, say, C# or Java?}

Yes, semantics are useful, but that does not mean they are objective. There are lots of UsefulLies that humans rely on as communication tools even though they are not rigorously defined. That's life. As far as the objectivity of I/O, search for 'agree on what "output" is (luckily)'.

{Semantics are more than useful; without them a language is just a grammar. A grammar only defines correct syntax. With just a grammar, we could write syntactically correct programs but they couldn't do anything because we couldn't write an interpreter. We could write a parser, but once the parser has parsed our syntactically-correct source code, without semantics we'd have no idea what to do with the AbstractSyntaxTree. Semantics tell us what to do with the nodes in the tree. Semantics are most certainly objective -- they describe precisely what the language statements do. Ultimately, they describe precisely what is done to the real values in the real memory locations on real machines, though we usually employ several levels of indirection so we don't have to jump from language statements to bit-twiddling on specific machine architectures.}

Okay, I'll agree that "semantics are required for the tool to be useful". But that's not the same as clarity or singularity being required. There are multiple models for "do". There are multiple different models that can transform the "I" to the "O" with regard to I/O. You have not proven that your model of "value" is required for all possible accurate models. That proof is your job, not mine. You also keep flipping between 1) suggesting your model is the best fit for current WetWare (common notions) even IF there are alternatives, and 2) your "value" model is the only valid model (or a required part of all accurate models). Please be clear about which position you defending. -t

{If you claim to have an alternative to conventional semantics, then you're implicitly claiming that you have alternative (simpler? faster? better?) ways to build interpreters. That's what "multiple models for 'do'" implies, whether you're interested in interpreter/compiler implementation or not. If so, can you show a simpler, clearer, whatever way -- than that shown later on this page -- to implement a canonical popular imperative programming language statement like "a = b + foo() * (bar() + 3);"?}

Again again again again again again again again, you have NOT established a canonical "conventional semantics". You just THINK you have because you are stubborn by nature. And again again again, I don't claim my model is objectively simpler. It's designed use to communication and modelling techniques that programmers have to use as part of their job, reducing communication problems. I don't have to borrow obscure gobbledygook from academic books that few read or like. Further, it's designed to optimize human grokking, not computing resources. It would would probably be slow and memory-hungry if actually implemented.

{I don't know what "obscure gobbledygook" you're referring to -- any and all terminology I've employed is used in precisely the manner it's used in typical language documentation, introductory ComputerScience textbooks (which are hardly academic), and on-line popular and recognised sources like Wikipedia. I've never mentioned computing resources, so I'm not sure why that matters, nor do I expect anyone to implement a language using XML as an internal representation so "slow and memory-hungry" is irrelevant. It's already quite clear that you're using XML as an illustration because you feel it will be more familiar to your target audience. I have no significant objection to that. I object particularly to the following:}

You are only claiming that. Take some snippets and dissect them word-for-word to prove your claim.

{I'm only claiming what?}

Re: "all terminology I've employed is used in precisely the manner it's used in typical language..."

{Type, value, literal, variable, representation, operator, operand, argument and parameter are all terms I've used. I have used all in a conventional manner. If you believe otherwise, please indicate where I have done so.}

I held my Conventional-Manner-O-Meter up to your model, and it gave it a low score of 2.3. If you cannot afford this device, too bad. I'll sell you one for $699 plus tax. It's a good thing these devices exist, otherwise we'd be stuck with annoying repetitious personal anecdotes.

{Your facetious response does nothing to contradict what I wrote.}

You have NOT verified your "precisely" claim. It's just a claim. I claim snarboos are gloffniks, and that makes it so!

{I invite you to find examples where my use of type, value, literal, variable, representation, operator, operand, argument and parameter differ significantly and conceptually from that in recognised sources.}

I can't falsify matches against vague terms/descriptions, but that doesn't true-ify them either. Prove Nibbobs are not Truglumps! And this "recognized" thing smells suspicious.

{What's suspicious about using, say, Petzold's "Code: The Hidden Language of Computer Hardware and Software" as a reference? It's respected and well-known, i.e., "recognised". All the terms I've mentioned have established definitions. What makes you think they're vague?}

Foot Notes

[1] Fully understanding the guts of interpreters or computers is only part what makes good programmers good. Understanding team WetWare, getting along with people, and understanding user and org needs and WetWare, and having discipline etc. also count.

Note that the phrase I used was "weak programmers", not "weak developers". A weak programmer can be a good developer, for precisely the reasons you mention.

My point is that being slow with academic-centric materials does not make them useless or unproductive as programmers/developers. They may not be the best person to answer the most technical of questions or tricky real-world puzzles, but that's only part of the job. Your implication was that if they don't absorb your pet materials, they should find a different career. It smells of StuckOnPetFactors. Some of the best teams I've been in have a verity of minds such that each collaborate and contribute based on his/her personal strengths. It's comparable to a basketball team where variety of talents work together to target the other team's weak-spots. You have short but quick guys (point guards), and slow but muscled giants to grab rebounds and defend close to the basket. You also have those who are not so athletic nor tall, but are dead accurate shooters from the outside. And you have skilled defenders who are sub-par shooters, but can stop the best guy on the other team. On rare occasions some players can fill two or three of these roles, and are the superstars of the sport. But they are also expensive and rare.

My descriptions are not "pet materials", they're simply how popular imperative programming languages actually work, are typically documented, and are generally understood by strong programmers. If your model was obviously simpler, clearer, and more effective than conventional explanations of types, variables and values, then it would be worthwhile. I see no evidence that it's obviously simpler, clearer, or more effective than conventional explanations. What would unquestionably benefit weak programmers is better-written conventional explanations, not whole new models that differ from conventional explanations without being any simpler or easier to understand.

I've already discussed why actual implementation is not relevant and I won't reinvent those arguments here. I believe them to be sound and rational, and if you disagree, so be it. Some debates are never settled despite 200 repeats. I've had political debates like that with relatives. Please stop bringing it up unless you enjoy repetition. And being a "clearer" model may depend on WetWare. Obviously it's a poor fit for you. Even if we ignore "simplicity", my model takes a very different angle such that if one presentation approach fails for an individual, perhaps another will work. Some believe intelligence level is "linear" in that either one is smart or stupid or something in between on a linear continuum. You hint at such a view when you divide programmers into "strong" and "weak". This is a poor model of intelligence in my experience because some people just need input (lessons) in the right format to click for them. I came from a family of professional artists and am a visual thinker. I like visual and "mechanical" models. Many in IT are also "linguistic thinkers"; they like to mentally process symbols and relationships between symbols. That's an over-simplification, but it's a rough pattern I see among techies, and the visualites often don't see eye-to-eye with the linguites. My brother is also a visualite. He started out in electronics engineering in school, but switched to mechanical engineering because he had trouble relating to the non-physical nature of electricity and its "odd" math. I was really good at math problems that had a (known) visual counterpart, but clumsier at those which didn't. (There are also "social thinkers", who are more often in sales. The best sales people are "social rocket scientists", one could say.) -t

I accept that maybe a completely different model will work for some people. My problem with your model is that it isn't completely different. It's almost the same as the conventional explanations, differing only in small (but important, maybe even crucial) details. That can only lead to confusion.

Only if they are first indoctrinated with your style of model. A side note can show the nested XML version. I don't want to keep repeating the nested version; it's bloat: 

   State 1: Sample sample blah blah blah
   .
   .  <var name="foo" type="number" value="123">
   .
   State 2: Sample sample blah blah blah
   .
   .  <var name="foo" type="string" value="123">
   .
   State 3: Sample sample blah blah blah
   .
   .  <var name="foo" type="string" value="moof">
   .
   State 4: Sample sample blah blah blah MultiValued  // [not added by -top]
   .
   .  <var name="foo" type="string">
   .    <value="boof">
   .    <value="woof">
   .    <value="doof">
   .    <value="moof">
   .  </var>
   .  // You ruined my example, guys. This was NOT about arrays. --top
   .  // SEE toward the bottom for a restoration of the original. --top
   .  // By the way '<value="moof">', that's not valid XML.
Versus: 

   State 1: Sample sample blah blah blah
   .
   .  <var name="foo">
   .    <value type="number" representation="123">
   .  </var>
   .
   State 2: Sample sample blah blah blah
   .
   .  <var name="foo">
   .    <value type="string" representation="123">
   .  </var>
   .
   State 3: Sample sample blah blah blah
   .
   .  <var name="foo">
   .    <value type="string" representation="moof">
   .  </var>
   .


   State 4: Heterogeneous MultiValues
   [ I did NOT add this 4 thing. I don't know what it's for or why it's here.  --top]
   [ "State" was meant as a sample step, not "example number". --top]
   [ Please be careful about attribution. --top]
   [ And a good many arrays don't allow mixing explicit types, which ]
   [ below is poorly factored for. --top]
   [ A good many do allow array elements of mixed types, for which the following is entirely reasonable. ]
   {  I hate to do this, but in fairness to those who do not like heterogeneous arrays, I have added a Stage 4 homogeneous array above.]
   .
   .  <var name="foo">
   .    <value type="number" representation="123">
   .    <value type="string" representation="123">
   .    <value type="string" representation="moof">
   .  </var>
   .
    (There is no state 4 for the first although it can represent homogeneous MultiValues)
(Dots to work around wiki formatting glitch.)

The first is much less clutter and easier to read to my WetWare. I optimized the structure for the documentation and usage in the model kit, NOT some future purpose (YagNi). Most readers won't give a shit about actual interpreter building. Why should I burden 95% for the sake of 5%? That doesn't seem rational to me. Spock kicks you. I suspect you are again going to argue for formula/tuple notation instead to "solve" the bloat. But I won't repeat that fight here. I'm sticking with XML and if you don't like it, suffer in the twisted anguish you deserve for being stubborn and detached from the field.

But variables in DynamicallyTyped languages don't need types and don't benefit from having them. Try working through execution of the statement "a = b + foo() * (bar() + 3);" using both approaches. Assume foo() and bar() return numeric values and b contains the string "Result: ". 

      // Illustration of a = b + foo() * (bar() + 3);
      // execute bar(); the returned value is v1
      v1 ← invoke('bar')
      // convert the literal "3" in the source code to value v2
      v2 ← convert_numeric_literal_to_value("3")
      // add v1 and v2; the result is v3
      v3 ← add(v1, v2)    // use numeric addition for +, because v1 and v2 are numeric (i.e., v1(t) = v2(t) = numeric).
      // execute foo(); the returned value is v4
      v4 ← invoke('foo')
      // multiply v4 and v3; the result is v5
      v5 ← multiply(v4, v3)
      // put the value in variable 'b' in v6
      v6 ← retrieve_from_variable('b')
      // convert numeric value v5 to string value v7
      v7 ← convert_to_string(v5)     // use concatenation for + because v6 is a string (i.e., v6(t) = string), but first convert v5 to a string
      // concatenate v7 onto v6; the result is v8
      v8 ← concatenate(v6, v7)   
      // store value v8 in variable 'a'
      assign_to_variable('a', v8)
. {It would fail. Typed or not, adding "Result: " to any number is difficult to achieve. I obviously don't understand what you are getting at.}

Assume the + operator is overloaded, and can represent either numeric addition or string concatenation depending on the types of its operands. This is found in Javascript, Java, C#, Python and many other languages.

{It would fail, overloaded or not. What is it you are trying to say?}

Why would it fail? Imagine that foo() returns 3 and bar() returns 7. So, let's examine how a real interpreter might process it: 

      a = b + foo() * (bar() + 3);
      a = b + foo() * (7 + 3);
      a = b + foo() * 10;
      a = b + 3 * 10;
      a = b + 30;
      a = "Result: " + 30;
      a = "Result: 30";
{You are right. It would work, but it does demonstrate the folly of overloading.}

Perhaps, but that's a language design decision. The concerns here are about language implementation and modelling.

We could model it like this, where v1 .. vn are values such that v=(r,t) where r is a representation (e.g., a sequence of binary digits) and t is a type reference. 

      v1 ← invoke('bar')
      v2 ← convert_numeric_literal_to_value("3")
      v3 ← add(v1, v2)    // use numeric addition for +, because v1 and v2 are numeric (i.e., v1(t) = v2(t) = numeric).
      v4 ← invoke('foo')
      v5 ← multiply(v4, v3)
      v6 ← retrieve_from_variable('b')
      v7 ← convert_to_string(v5)     // use concatenation for + because v6 is a string (i.e., v6(t) = string), but first convert v5 to a string
      v8 ← concatenate(v6, v7)   
      assign_to_variable('a', v8)
Note that the only operations we need on variables are value ← retrieve_from_variable(name) and assign_to_variable(name, value). Variables are merely an association between a value and a name; we don't need variables to have a "type" property. Only values (v1 .. vn) need a "type" property v(t), which we use to decide (as shown in the above example) whether to use add(value1, value2) or concatenate(value1, value2).

In a real implementation, it's not uncommon for a stack to be used to hold values so the above might be implemented as: 

      push(invoke('bar'))
      push(convert_numeric_literal_to_value("3"))
      push(add(pop(), pop())) 
      push(invoke('foo'))
      push(multiply(pop(), pop()))
      push(convert_to_string(pop()))
      push(retrieve_from_variable('b'))
      push(concatenate(pop(), pop()))   
      assign_to_variable('a', pop())
If we want to be pedantic, we can note that add(), multiply() and concatenate() are almost certainly low-level operators that expect and produce representations rather than values (as defined here). So, in the interest of stricter accuracy we can add a value ← create_value(representation, type) operator and re-write one of the above examples as: 
      // Example 376
      v1 ← invoke('bar')
      v2 ← convert_numeric_literal_to_value("3")
      r1 ← add(v1.r, v2.r)             // use numeric addition for +, because v1 and v2 are numeric (i.e., v1.t = v2.t = numeric)
      v3 ← create_value(r1, numeric)
      v4 ← invoke('foo')
      r2 ← multiply(v4.r, v3.r)
      v5 ← create_value(r2, numeric)
      v6 ← retrieve_from_variable('b')
      v7 ← convert_to_string(v5)       // use concatenation for +, because v6 is a string (i.e., v6.t = string), but first convert v5 to a string
      r3 ← concatenate(v6.r, v7.r)
      v8 ← create_value(r3, string)   
      assign_to_variable('a', v8)
You know, those look a lot like hidden variables to me. And "v6.t" suggests a flattened structure instead of your nested structure, which would be addressed more like "v6.value.t". -t

If they look a lot like "hidden variables" to you, then it seems you're using the term "hidden variable" to mean "value". That's fine, but nobody else is going to recognise your use of the term "hidden variable" unless you're careful to point out that you say "hidden variable" where most others say "value". And "v6.t" is correct, because v6 is a value so v6.t is the value's type. Keep in mind that the above is an illustration, rather than a copy of some implementation. The values that are numbered for illustration purposes above would not have names or numbers in any real implementation; they'd most likely (as is shown above) be pushed to and popped from a stack.

But that's for machine efficiency. A given model doesn't need to care about machine efficiency, especially if it's for humans to digest instead of (only) machines. And they look and act more like variables to me THERE than "values". Your own examples and descriptions of them are helping me demonstrate my point. Thank You. This is especially telling: "The values that are numbered for illustration purposes above would not have names or numbers in any real implementation."

Yes, it is telling: It clearly distinguishes the model of language semantics from an application of the model. The former does not require names to be associated with values. In the model (and in conventional semantics), variables and constants have names, do not have types, and contain values. Values do not have names, and they have types. This is the conventional "model" that we use to understand popular imperative DynamicallyTyped programming language semantics, and it is sufficient to create illustrations like that shown above. In illustrations (like the above) that use the model, we might wish to label the values under consideration, just as we might wish to number the individual lines of pseudo-code. Obviously, the line numbers are not part of an interpreter at run-time! Likewise, the named values are not components of the model, and they certainly aren't components of what we're modelling -- they are only notational conveniences that we might use to illustrate how the model works in a particular scenario. In another scenario, I might not label values. Hence, values do not possess a "label" or "name" property.

However, the main point of the illustration above is not whether or not elements of the illustration of the application of the model have names and types, but whether what is being modelled -- i.e., variables -- have both name and type properties. The above clearly shows that the only operations performed on programming language variables -- e.g., 'a' and 'b', above -- is to retrieve a value or store a value. Thus, there is never a need to obtain the "type of a variable", and so there is no need to model programming language variables has having a "type" property.

Perhaps there is an alternative interpretation (pun intended) of popular DynamicallyTyped programming languages that has no values and relies on variables having a "type" property. If so, I'd like to see it using the same approach used above. That way, we could compare the approaches side-by-side. You've claimed, several times, that your model is simpler and more intuitive than the conventional model illustrated above. If that's the case, I'd like to see an illustration to back up your claim of simplicity.

The key data structure is simpler, for one, as normal people can see below in the "Original XML comparison example". Whether the rest is "simpler" or "more intuitive" may depend on WetWare. Again, you are not a representative specimen to test that in part due to your heavy exposure to a particular model. I find your writing and documenting style difficult and obtuse.

Yes, I recognise that you find my writing and documenting style difficult and obtuse. That's why I suggest you demonstrate the application of your model using pseudo-code, just as I've done. That way, we can compare models without getting lost in verbiage.

And I agree that a model may not "need" to label certain things to function (match I/O), but that doesn't mean we cannot do it. A model meant to optimize human consumption may not be optimized for machine consumption and vice verse. If labels improve the model for human grokking, I'll use them EVEN if they bloat up OTHER areas. This should go without stating and be obvious to rational people. Further, it's not a minimalism-only contest. Many factors need to be balanced. We don't "need" your model's values and nesting either. (There may also be trade-offs between speed and size.)

You appear to be conflating application of a model -- for which (e.g.) labelling is entirely appropriate -- with the model itself. As for not needing values -- as I've suggested, please demonstrate application of your model using pseudo-code, as I've done above, without reference to values.

Further, you admitted that we don't HAVE TO package the type indicator and the representation together. You claim the packaging has nice design features, but putting that aside for the moment, your admission means that a proper model (matching I/O) CAN exist without your two-attribute "value" thingy. True?

In general, no. Unless the type attribute is implicit (e.g., all representations are character strings, so an explicit type attribute is unnecessary), it's impossible to perform operations on values without the interpreter having access to both a value's representation and its type. Without a representation, what do operations use as operands? Without a type, how does the system know what operation to perform? That said, when the interpreter knows the type of a value, sometimes the representation is unbundled from it in order to perform a low-level operation, but the result is then bundled back into a value.

You seem to be presuming that operations "happen on values" and that values exist. It's circular logic. That's your personal preference, not a universal truth. We can model operators as acting on the type indicator and on the representation without pre-packaging them.

Conventional popular imperative programming language semantics define operators as operating on values, so it seems rather odd to arbitrarily deviate from conventional understanding of language behaviour. Furthermore, type references and representations will almost invariably be used together, so it seems reasonable to treat them as a unit. However, yes, you can act on the "type indicator" and the representation independently -- and there are implementation reasons, as I noted above, for sometimes doing so -- but from a modelling point of view, what would be gained by doing so?

I agree it would be "reasonable" to group them (at least, possibly with other attributes). But above was a hypothetical proposal to tease out possibilities, not a design choice in terms of software engineering quality. It's a for-the-sake-of-argument scenario to build on something you agreed on rather than start from scratch. As far as your alleged "standard semantics", it either does not exist or is one of many overloaded vocabulary kits in colloquial land. You put too much stock in such an alleged verbal "system". You seemed to agree elsewhere that "value" was overloaded in colloquial speech, or at least sloppily used for multiple purposes. You seem to be cherry picking which usage instance is deemed "official" versus casual (sloppy).

Conventional semantics are found in every first-year programming and/or ComputerScience textbook, and the majority of language reference manuals for popular imperative programming languages.

Such materials are not careful with vocabulary. Or at least one cannot tell the difference between terms meant to be precise/clear/rigorous and those meant colloquially. You have agreed the online documentation for Php is poor, and it's one of the top dynamic languages (for good or bad). How does one know if they are looking at good documentation instead of Php-like documentation unless there are clear ways to test on one's own?

Whether they're well-written or not -- which is a separate issue entirely -- the semantics they describe (once you allow for terminological blunders) are consistent. Popular imperative programming languages all have the same semantics within their given category, i.e., Category S, Category D1 and Category D2, as described on TypeSystemCategoriesInImperativeLanguages. That's precisely what enables programmers to easily move from one popular imperative programming language to another, with only some effort to learn differing syntax and library routines.

I disagree with this assessment, as stated elsewhere on this page. One can use types "good enough" with just fuzzy notions and pattern-based experience.

When developers move from C# to Java, or Java to C#, do you think they find it difficult?

Those are generally considered "static typed" languages. Static typing is generally clearer than dynamic with regard to types because of the explicitness required and (mostly) lack of run-time type mutability. And people can move around dynamic languages fairly easily also; I've done it myself without knowing the typing details of each specific language. There are various rules of thumb and tricks to work around type-related issues in dynamic langs that don't require a rigid/clear model of their type system.

Why do you think people can "move around dynamic languages fairly easily"?

I know I've answered this at least 5 times already. To hell with #6! Your forgetfulness is becoming concerning.

Really? People can "move around dynamic languages fairly easily" for an obvious reason: Popular imperative DynamicallyTyped languages share common semantics. If they didn't, "a = foo() + b;" might mean "invoke operator foo and add its return value to the value in variable 'b', and assign the resulting value to variable 'a'" in one language, whilst in another language it might mean "categorise tuple generator 'foo' according to the relationship defined by 'b', using Shlaer's Algorithm to rotate the '+' spindle (partial, it's degree-n only!) against the convolution (secondary, but beware of functional tropisms to isomorphism) of partition 'a'." Fortunately, similar syntax across all popular imperative programming languages implies almost identical semantics. Variations are minimal, and fall into the three categories described at the top of TypeSystemCategoriesInImperativeLanguages.

Some may indeed use the second Shlaer model. People use all kinds of different head models that are GoodEnough to finish their tasks. That's one of the GREAT LIFE LESSONS I have learned the hard way. I've talked before about suspected differences between "linguistic" thinkers versus "visual" thinkers. Similar syntax only means similar syntax, NOT similar syntax processing. Syntax is a poor reference for head models other than the starting input. I bet monkeys could recognize syntax if coaxed with food for long enough. -t

The "Shlaer model" is fictional, an illustration of hypothetical alien semantics for familiar syntax. It is only because language semantics are consistent across languages that it is possible to recognise that similar syntax -- such as expressions, variable assignment, operator invocation, etc. -- reflects almost identical semantics. This has nothing to do with "all kinds of different head models". There is clearly a consistent and conventional "head model", or it would not be possible to "move around dynamic languages fairly easily."

Bull. You have not proven that your version of "semantics" is the only possible model to transform input (including source) into output. And like I've said elsewhere, many start using D2 languages such as CF without ever knowing it's a D2 language or that D2 languages even exist. The differences are relatively subtle and can be worked around on a case-by-case basis without overhauling one's head model (change D1 to D2 in head). And many adopt defensive programming so that they don't have to worry about "drifting" types. If something goes awry, they often shore up their defense, not their head model. I often do that with new languages, but over time I start to probe type behavior to avoid defense bloat. -t

Why have you switched to arguing that I have not proven that "my" version of semantics is the only possible model? It obviously isn't, as proven by the existence of FunctionalProgramming and LogicProgramming. What does what programmers don't know about Category D2 languages have to do with this? The discussion here was about why people can "move around dynamic languages fairly easily". The obvious answer is that it's because dynamic languages share a common semantics associated with similar syntax. The differences are precisely what are documented at the top of TypeSystemCategoriesInImperativeLanguages.

You don't need a common head model to match external behavior. TuringEquivalency. Using an AI illustration, one may match behavior using neural nets, and another using genetic algorithms. Both "work" for prediction, despite having very little in common. (The human mind probably uses multiple AI-category-like techniques to triangulate answers, but diff people probably lean on some techniques far more than others.)

Regardless how individuals may construct mental models, the semantics they are modelling are consistent across popular imperative programming languages. That allows people to "move around dynamic languages fairly easily". If language semantics varied significantly from language to language, that wouldn't be possible, independent of what mental models people happen to construct.

Your "semantics" is not measurable in any objective way, and so I cannot verify your claim. You don't need a common head model to match external behavior, period!

Measurable or not, consistent semantics exist. The fact that programmers can move from Python to Ruby, for example, without re-learning from scratch, is ample evidence.

That's weak evidence to me and I've given examples from AI to demonstrate that prediction matching is not equivalent to process matching. Repeating it over again repeatedly does not make it strong evidence. But I'm tired of re-debating this "switch" thing. LetTheReaderDecide if it's strong evidence. Cap it off.

That does nothing to contradict my point. I don't know what your "AI illustration" is intended to show. What does the trivial recognition that "a = foo() + 2" in Python has the same semantics as "a = foo() + 2" in Ruby have to do with neural networks or genetic algorithms?

Yes it does contradict. Your statement implies that same results implies same process, which I have demonstrated to not be a universal truth in a general sense. And you have not measured "semantics" to demonstrate that identical semantics are being used for different expression processors (humans or machine). If both machine x and machine y take inputs a and b and produce the same output c, that is not definitive evidence that machine x and y are the same or use the same "semantics" (cough).

And like I keep pointing out, one can use the wrong model and still be GoodEnough to get work done. I used D1 assumptions on CF (D2) at first and for quite a while and never noticed the difference, spot-fixing any problem areas (typically by adding explicit conversion, explicit validation, or fixing the source data of input parameters, such as forms, to make sure they come in as expected.)

How does this answer my question? Again, what does the trivial recognition that "a = foo() + 2" in Python has the same semantics as "a = foo() + 2" in Ruby -- and, indeed, the same semantics in every popular imperative programming language where "a = foo() + 2;" is a syntactically-valid statement (which is most of them) -- have to do with neural networks, genetic algorithms, or (from your latest response) the "same process"?

In input->processX->output, if input and output matches for different instances of processX, that is not solid proof that the instances of processX are the same. Different models (both head and machine) can match OTHER models in terms of predicting output sets based on inputs sets. And until you scientifically isolate and measure this "language semantics" of yours, it's pointless to keep talking about it. You might as well be talking about unicorns and bigfoot.

As I've pointed out above and elsewhere, languages cannot be implemented in real interpreters and compilers without language semantics. Yet again, you seem to be ignoring (or evading?) the indubitable fact that "a = foo() + 2" in Python has the same semantics as "a = foo() + 2" in Ruby -- and, indeed, the same semantics in every popular imperative programming language where "a = foo() + 2;" is a syntactically-valid statement.

I'm skeptical. Can you prove mathematically or scientifically this is the case? I will tentatively agree that SOME kind of semantics are needed to implement languages, but I don't agree they have to be the same per implementation. Maybe some degree of similarity is necessary, but I don't know whether it's 5%, 50%, 90%, etc. Without a way to isolate and scientifically study such "semantics", it will be very difficult to do. Syntax and I/O is something we can objectively analyze. The "in between" processing is not (barring making implementation define a language, which I don't). Thus, please be careful about the distinction between 1) the existence of semantics being necessary and 2) semantics being "the same" across implementations/models/languages/heads.

(Note that the I/O characteristics of an implementation defining a programming language is different from the actual implementation defining the language.)

Can I mathematically prove it's the case? No, that would be like mathematically proving "there is integral calculus", which isn't how it works. Can I scientifically prove it's the case? Sure, and you can too. Read the documentation for every popular imperative programming language you can find. In how many of them is there a close syntactic equivalent to "a = foo() + 2 + c;" that means "invoke function foo() and add the resulting value to the value represented by the literal "2" and the value in variable c, storing the result in variable 'a'"?

Like I've said before, one could also just say "results" instead of "resulting value". Further, I've rarely heard it described like you worded it. That's a projection of your mind's model, not necessarily a canonical view. I'm not saying nobody shares that view, but that's it not the only possibility and not the only way others would likely describe it. One could just as well say, "take the result of foo, add the number 2 to it, and then add that result to what's in 'c'."

Yes, you could say "take the result of foo, add the number 2 to it, and then add that result to what's in 'c'", and that would be an appropriate shorthand. Obviously, "result" is just shorthand for "resulting value". The semantics are still the same, just less detailed. You could also say, "the expression is evaluated and the result stored in 'a'" or "the expression's result is stored in a variable." These are all semantically equivalent, differing only in detail.

And "how it works" has no objectively canonical form. Maybe there are multiple paths to how integral calculus "works". Why assume there is One True Path without objective evidence? And what exactly does "works" mean anyhow? We use human-world words to describe virtual or abstract worlds, but it often is a just a poor fit. Reading other references you give reinforces this.

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

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

Replies continued at ValueExistenceProofTwo, PageAnchor manuals_472

Original XML comparison example. 

   State 1: Sample sample blah blah blah
   .
   .  <var name="foo" type="number" value="123">
   .
   State 2: Sample sample blah blah blah
   .
   .  <var name="foo" type="string" value="123">
   .
   State 3: Sample sample blah blah blah
   .
   .  <var name="foo" type="string" value="moof">
   .
Versus: 

   State 1: Sample sample blah blah blah
   .
   .  <var name="foo">
   .    <value type="number" representation="123">
   .  </var>
   .
   State 2: Sample sample blah blah blah
   .
   .  <var name="foo">
   .    <value type="string" representation="123">
   .  </var>
   .
   State 3: Sample sample blah blah blah
   .
   .  <var name="foo">
   .    <value type="string" representation="moof">
   .  </var>
   .

{A value is the data. A value makes an individual attribute the attribute that it is. A value is the attribute.

The value's type is a small part of the metadata which may accompany the value. The type is one of the things about the attribute.

Is the "tag" meant to represent more than "type"?}

I've never seen evidence that "tag" represents anything other than "type", or more specifically "type reference" (as opposed to "type definition"). What's an "individual attribute"?

{I have never seen evidence that "tag" represents anything. I am still wondering what Top means by tag. That is why I keep throwing in my little statements - hoping for an "ah-aah" moment when I think "Now I know what a tag is - we can define it in a page and get rid of all this thread-mode discussion"}

(The context appears to have been messed up or lost here. I don't know what this is about.)

It appears to have originated as a self-contained comment.

See Also: ValueExistenceProofTwo

CategoryMetaDiscussion

NovemberThirteen

EditText of this page (last edited April 22, 2014) or FindPage with title or text search