Mapping Theory To Runnable Models

Based on discussion at TypesAndAssociations.

Re: "I am summarising..." - That's the problem, the reader can't see the details that go into the summary. And one book does not a canon make. It is possible to do proper textual analysis of multiple sources, but you have skipped that work, and then harass me for not accepting your authoritative summary. Either do it right or pipe down about canons. Put some real details behind your claims like the "proper" academic you claim to be. [reworked from original]

See pages 12, 13 and 283 of http://www.dcs.warwick.ac.uk/~hugh/TTM/DTATRM.pdf Their terminology (and writing style) is slightly nuanced, as reflects its academic audience and subject matter. Almost any standard 1st year text on ComputerScience will provide equivalent conventional explanations.

It describes a theoretical or conceptual model. I have no problem with that per se, but one book does not make it a canon, nor says anything about runnable models. We can pretend there is only one integer value "12" in the universe in a kind of existential sense (as described by the link, particularly page 13), but it's usually not PRACTICAL for a runnable model to reference a single instance of that "12" in order to mirror this existential uniqueness. Your model doesn't do it nor does mine. (For example, we could make a giant list of all known integers, or at least a "test set", and only reference them via pointers/ID's instead of putting values like "12" directly "in" our data structure for a variable/value.) -t

Even IF one accepts the existential canon that there is one and only one value "12" in the universe, no practical model can mirror that conceptual view. Even YOU chose not to in your model, duplicating "12" if two more variables share the "same value" of 12. I'm not going to complicate my model to mirror an existential view either. You took the practical route for "12", but why won't you accept the same "reality/practicality adjustment" for the structuring of a "variable"? -t

It appears to be hypocrisy at face value. I suppose you could argue that mirroring the (alleged) existential canon view of "values" (with type indicator and "representation" packaged closely together) is far easier than modeling the existential uniqueness of integer values (and reals, gulp) and thus you follow existential theory (ET) for the easier-to-model portions but not the hard-to-model portions of ET. This is a reasonable rule in my opinion, but I'd like confirmation this is the case with your design. My model is optimized for behavior prediction (IoProfile) and not ET. Thus, I chose not to complicate it to match ET. Most production developers don't care about ET and are not going into academics. -t

I have no idea what that means. "Existential theory"???

Perhaps there is a better word for it. Quote from page 13 of your link:

• "For example, the integer value 12 occurs exactly once in the set of integers—there is exactly one integer 12 "in the universe," as it were..."

We "pretend" there is only one "instance" of 12 in the universe, per theory of integers.

How many different twelves are there? Last time I checked, there was only one, between eleven and thirteen.

• {Isn't there also a 12 on the clock, between 11 and 1? There's also the "12" I just typed between spaces in the language domain (and this one: *twelve*).},

• Are they integers? If they are, they're mostly different literals for the same integer value 12.

• {How is it the same integer value 12, if 1 follows it?},

• It might simply be the integers from 1 to 12, in which case it's the same 12. Or it might not be the integers at all, in which case it's a different 12 with the same literal.

• {But didn't you say that types are a set of literals plus operators upon them? Let's define a successor operator to increment integers. Then the successor to 12 in your integer theory is 13, but in "clock theory" it's 1.},

• No, a type is a set of values and zero or more associated operators. Sounds like the "clock theory" type isn't the integers.

• {Well, it (clock-type) is (or can be defined as) a "set of values and zero or more associated operators". What's different about it?},

• [It's Z_12 (the 12 after the underscore should really be a subscript), not the integers. One, rather obvious, difference is the successor of 12 is 1 instead of 13.]

• {Who defines the integers.},

• [Mathematicians, of course. Just like any other field, they get to define their own terminology.]

• {Of course, you think? No. You might have defined "number", but you didn't create arithmetic. And I'm a mathematician, too, so how are you going to resolve that? And you certainly didn't create the integer type residing in the computer. A moment ago, you were arguing about "what other domains of integers are there?" and now you want to say there's only one domain (yours). So which is it?},

• What? This is simple: The integers are not the same type as Z_12.

• [To address your other question, what is there to resolve? The integers are a particular structure. Mathematically, it's irrelevant what its origin is. All that matters is what the structure is.]

In existential theory-land, yes. But not in Practical Land. You didn't choose to model values around that uniqueness concept.

It simply isn't an issue; the standard model doesn't consider it or not consider it. It is sufficient for a variable to be a reference to a value. Whether two variables reference the same value or different values is immaterial.

I'm not clear on this. Are you saying in some cases it's "okay" to violate OnceAndOnlyOnce, but not in others (outside of wrong final results)?

It simply doesn't apply. It's an abstraction, not an implementation. There's no need, at an abstract level, to define how (or if) OnceAndOnlyOnce is implemented, because even if we define a system in which there are multiple value implementations that each represent the integer 12, we presume they all demonstrate equality, and thus the perception will be that there is one 12.

If only the final perception (I/O) matters, then why complain about other models that have matching IoProfiles (match interpreter behavior), but don't (allegedly) "fit" the abstraction notions very well. You seem to be cherry-picking which deviations from the "proper abstract model" are acceptable deviations for runnable models and which are not.

This has nothing to do with I/O. I didn't mention I/O. It's about semantics. At an abstract level, semantically, every integer value 3 is the same integer value 3.

What do you mean by "perception" then? Who's perception? The language user (runner of the emulator) or the model administrator/analyst? And we have a very different viewpoint about what "semantics" means such that using that word around me from you is unlikely to convey any useful communication. Per prior ThreadMesses, to me, semantics happens "in the head", not (typical) machines. It's not something that can (currently) be objectively and/or scientifically analyzed.

I mean the user's (i.e., the reader's) perception of the model. If the model is implemented, then it's the user's perception of the resulting system. As a user of a typical imperative programming language, I can't see whether the 3 in variable V is represented by the same internal object as the 3 in variable P or a different one, but it doesn't matter. 3 is 3.

• This appears to contradict your complaints that the internal parts of TopsTagModelTwo don't fit theoretical design (or internal "semantics" or something).

• My complaint is that your variables don't match the semantics of popular imperative DynamicallyTyped languages, and your values don't match the conventional definition of values, and you're creating terminology without defining it, like "type tag".

• It looks like flip-flopping or cherry-picking "internal rules" to me. If "matching theory" matters to the internals, then we should reference "3" just once rather than store duplicates of it (probably using pointers). That would better fit Date's vision, which you cited.

• It just doesn't enter into the picture. From the point of view of the conventional model, a value is a value. There's no need to mention, at that abstract level, whether or not some mechanism exists to ensure values are unique and exist OnceAndOnlyOnce. That's an implementation concern. As a model, they're values, so each value of a given type implicitly exists OnceAndOnlyOnce because that's what a value is. We don't have to enforce what a value is, because it's a value.

• Okay, but a "value" is also model-specific. A language user never actually sees a "value". They see literals, and output results, which are technically a form of "literals", even though they are often called "values". I will agree the existence of "value" is a useful metaphor (or UsefulLie), but it doesn't have to actually exist, at least not in a consistent form [1]. Syntax-based elements can objectively exist per language grammar/parsing rules (if it's surrounded with quotes and it's between such and such a character pattern, then it's a Foo"). Values don't objectively exist.

• Values are not only fundamental to basic arithmetic, they're fundamental to programming language semantics. What does a function return? What does a variable contain? What does an expression evaluate to? You can't answer these questions without reference to values.

• "Results". Any further refinement in classification is arbitrary and/or internal implementation detail. "Value" is often colloquial short-hand for such, but it's also colloquial short-hand/stand-in for "literal". "Values" are a nebulous or theoretical mind object.

• What is a "results"? And why treat it as an "arbitrary and/or internal implementation detail" when it's known universally as a value?

• So are "literals", per above. It's a fuzzy catch-all. I can point to things on a screen and say "this IS a variable" and "this IS a literal" (per language syntax/grammar rules). There is no equivalent for "value".

• You're making the mistake of assuming that because every syntactic construct is mapped to a semantic construct, every semantic construct must be mapped to a syntactic construct. "Value" is a fundamental term in mathematics, and it's one of the BasicLanguageConcepts in ComputerScience. Avoiding it will cause confusion, rather than reducing it, especially when you try to explain language concepts like types.

• A corresponding syntactic construct is not required, but it is ONE WAY to have something objective to see and measure and test scientifically. If you have another way for "value", let's see it. And avoiding it hasn't caused any confusion that I have seen. And I'm suggesting the "traditional" definition of types is a poor fit for most dynamic languages, in part because it depends "ghost parts" like "values". -t

• There's no syntactic construct for "memory", either, but it's fundamental to ComputerScience and programming languages. Likewise, "value" is fundamental to ComputerScience, mathematics, and programming languages. You can't extract these from discussion of programming languages without making the discussion strange, awkward, and unfamiliar to those with even a smattering of familiarity with ComputerScience, mathematics, and programming languages. For example, virtually every programming language reference mentions values -- usually frequently. As for types and dynamic languages, the standard definition fits perfectly.

• "Memory" is a limited resource imposed by our existing hardware. However, over time a programmer has been able to be less and less concerned about it (outside of mobile). Some processes where I used to fret over memory, I code so without worry now: the code I'd write if memory was unlimited versus what it actually is (mildly limited) grows less and less different over time. And while I do agree that "value" is fundamental, it's also vague and ethereal. "Heaven" is fundamental to a religious society; they talk and think about it often, but it's also vague and ethereal. Thus, importance and specificness are not necessarily related. "Values" are part of pretend a fake or heavily idealized world. IF we use it in runnable models, then we have to arbitrarily flesh out details to make it specific enough to write algorithms around because computers don't process notions (in a reliable way). Similarly if you make a movie about "heaven" and want to show heaven, you have to flesh out specifics: the sky/background has to be SOME color for example, and there has to be some clothing style up there (or lack of clothes, heaven forbid, pun intended). VagueOrArbitrary. -t

• Why do you think values are vague or ethereal?

• Because they are. I don't know how else to put it. They have no objective presence when dealing with typical programming languages. Literals and output are projections of them, but they are not directly them. I suppose everything in a virtual world is projected to some extent, but values more so than the others. Their existence is not required to run a program. Maybe our hardware requires them (depending on how defined), but that's an implementation detail. They are often a UsefulLie when "running" programs in our head, but still not a necessity.

• That's an interesting interpretation. I find it difficult to imagine programming with variables, parameters, functions, and expressions, but variables aren't assigned values, parameters aren't passed values as arguments, functions don't return values, and expressions don't evaluate to values. I suppose you could call all of them "results" or "data", but then it seems you're just making "results" or "data" -- in those specific contexts -- somewhat oblique and generic synonyms for "values".

• You are completely missing my point. I don't know how you came to that. Whether they "exist" or not is generally moot. They do indeed make for a very UsefulLie if they don't exist. But the real issue here is that to "implement" them requires making some arbitrary decisions about their representation, similar to the heaven movie analogy above. Any "canon" made around them would have arbitrary decisions in them and would be a standard for the sake of standard in order to have a standard. To continue with religious analogies, nobody really knows what Jesus Christ looked like (assuming he was a real person). However, we have settled on a semi-specific representation as kind of a standardized avatar or icon so that the image is recognizable to most. We can do the same with "values", but only by accepting some arbitrariness.

• They certainly exist, even at the most fundamental (software) level: every memory address is a container for a value. The decision about what specific pattern of bits means an integer 3, or how and where the type 'integer' is associated with that integer value, is arbitrary and implementation-dependent. That a value must have a representation and be associated with a type is not arbitrary. In fact, it's logically unavoidable. A representation without a type is an unknown blob of data. A type with an empty representation is a null value; you can't perform any meaningful operation on it because there's no data upon which to perform a meaningful operation.

• Again, in dynamic languages "the association" is often situational in practice, and the interpretation of "the blob" is perhaps done at or by another system or a user's head. One does not have and/or use a God-level-view of every "operation" that may be involved. Thus, over-emphasizing the relationship with operators is often a UselessTruth. It's not a NATURAL way to view types in most dynamic languages. And I already addressed RAM: it's an arbitrary implementation detail.

• How is the association between a value representation and its type "situational"?

• When is the interpretation of a "blob" done in someone's head rather than the machine?

• How is the conventional definition of 'type' "not a natural way to view types"?

• Where and how is the relationship (of types?) with operators over-emphasized?

• I believe we've been over all of these in other topics. I do not wish to repeat those debates again at this time. I'll try to find the original discussions for each. My "quick and dirty" summary assessment is that we both have different views of the WetWare of typical existing developers, and no volume of debate is likely to change each of our assessments of such. -t

If semantics "happens in the head, not (typical) machines", then it seems we're imagining a lot of working interpreters and compilers. Semantics is a mapping from syntax to meanings. "Meaning" (I use the term loosely, here) happens in two places. One is what syntax means to us, e.g., "v = 3" means "3 is assigned to v". The other is what happens in the machine, e.g., "v = 3" results in a sequence of operators to be executed that causes a value 3 to be stored at a memory location associated with the variable identifier 'v'. Obviously, there needs to be an alignment between these, so that the semantics defined by a language designer are sufficiently detailed -- or make obvious reference to conventional semantics -- that a language implementer can translate the syntax into machine operations that recognisably and consistently implement the semantics.

Re: "we're imagining a lot of working interpreters..." - In a sense, yes. Our human brains define "working". The machines are just idiot savants. And "what happens in the machine" shouldn't matter as long as it processes the inputs (source and data) into the proper (human expected) output. If it uses gerbils, Osmond action figures, dental floss, and sun-dials, it shouldn't matter as long as it gives the right answer. If the guts do matter, then we need to identify when and why they matter. "Expected behavior" != Semantics. ("Behavior" being patterns of response to a given environment, where "environment" is typically the source code and any input data in this context.)

I've not mentioned anything about how a language implements the semantics of the language. You're right, it shouldn't matter, and it is orthogonal to this discussion.

You seem rather inclined to add complexity and philosophy to what is very simple and mechanical: Popular imperative programming languages have parts, and those parts have conventional names and behaviour, which are generalisations of what bits of code mean in source code, and what happens when the source code is executed.

We disagree on what this "conventional" is, where it is documented, and how to "properly" interpret such documents. They are vague, per my understanding of the English they use. And your arguments do appear to depend on philosophy. I didn't make that dependency happen.

That dependency appears to be solely your own interpretation, and you appear to erroneously conflate "abstract" with "vague".

If the writing is INTENDED to have a relationship to abstract theory, that relationship is not made clear. I have no problem with authors tying documentation of specific languages to abstract theory; but IF they go that route, then do it right: write clear, make relationships clear, don't assume anything. If you are going to tie, then tie right. Don't use a lazy slippery knot. If "has" in your book means something special beyond regular English, then friggen STATE SO.

I have no idea what that means.

Let's take it one word at a time. What's the first word or phrase that stumps you?

The words make sense, but the overall meaning is lost. What is the problem with "has"? What is not clear about relationships? If you want the concise clarity of a formal notation -- which shows relationships and associations as tuples -- it's at the bottom of TypeSystemCategoriesInImperativeLanguages.

But you are choosing an arbitrary representation/model, per VagueOrArbitrary. I've already explained the problem with "relationship" multiple times. EVERYTHING in a program is related to each to some degree, for example, because being in the same program is a relationship itself.

The framing of the relationship is self-evident, and it's neither vague nor arbitrary. Again you appear to be confusing "abstract" with "vague". If I say a value is associated with a type, it's quite evident that I mean something more than they're in the same program, especially if I haven't otherwise mentioned programs.

No, it's not "self-evident". Based on historical patterns and experience-based "intuition" around certain programming language families or topics, I may be able to make a similar guess to yours, but that's not the same as "self evidence". Spell out any assumptions: put everything on the table.

It is spelled out. Given "A is associated with B", or "A is related to B", or "A has B", if we know A, we know B.

What do you mean by "know"? Had drinks with after work?

In any context where "A is associated with B", or "A is related to B", or "A has B" is used, it always means the same thing: Given an A, we can answer questions about B. If it helps, pretend it's a table with two columns A and B where A is the primary key.

The devil is in what A and B actual "are" in a given model, and what questions we can answer both on a practical level and in theory.

No, "the devil" isn't in what A and B actually "are". If we say "A is associated with B", or "A is related to B", or "A has B", then we mean precisely that given A we know B, just as if we were given B.

[1] Re: "consistent form" - For example it may internally simplify an expression using logical or mathematical and/or "caching" deduction so that it internally only needs say 2 intermediate values, where-as we would need 5 if we did it "traditionally" on paper without the expression simplification or caching cheats. I will agree that existing technology needs some kind of value(s) to perform computations, but the nature of them and their relationship to syntax and data that the language user can actually see is open-ended. The machines' solving steps and processes don't have to match the "semantics" we learn in school on paper.

CategoryMostlyOffTopic

• Really? How is discussion of language semantics and terminology OffTopic for a Wiki about SoftwareDevelopment?

The topic is the page name.

• Oh, yeah, the PageName appears to have nothing to do with the discussion. It probably should be TypesAndAssociationsContinued.

Phew - I thought it may develop into another argument sub-thread. I only added the category because I liked the PageName and was a little disappointed at the contents. I know I could put in my opinion of what the page could contain (and I may later), at present I am reluctant because I don't want to be involved in the arguments. I liked the PageName because MappingTheoryToRunnableModels is, to me, a good summary of ApplicationDevelopment.

{MappingTheoryToRunnableModels describes the actual problem better, in my opinion. Others seem to see "the problem" in a different light, however. Titles sometimes make or echo assumptions that different contributors may not agree with. That's life in virtual CyberLand. -t},