Types And Associations

Continued from TypeSystemCategoriesInImperativeLanguagesTwo.

"Associated with" by itself doesn't tell us how many types can be "associated with" a variable/value, when the association occurs, when it goes away, and how we empirically test for its existence. In a tag-free language like CF, one could say the string "123" is "associated with numbers" because it can be "interpreted as" numeric, or can be said to have a value that belongs in the "set of numbers". And this could become actual implementation in that a lookup table of all possible numbers (within size/precision limits expected), as "numeric strings" (for lack of a better term), could be created.

By the usual rules of English language, "a variable is associated with a type" means a variable has one type, because of the phrase "a type" in which both "a" and "type" are singular. If a variable could be associated with multiple types, it would be written as "a variable is associated with multiple types" or "a variable is associated with types". Whilst it is not unreasonable to say that the string "123" is "associated with numbers", it's merely an awkward way of saying that "123" is a numeric string.

As for "when the association occurs, when it goes away", your phrase "has a tag" or "is associated with a tag" offers no more information about that than "has a type". The usual assumption about models is that unless stated otherwise, we can safely regard an association as existing in perpetuity unless stated otherwise. For example, in a model that refers to a set V {a, b, c}, we can assume a, b, and c have been elements of V since the beginning and will always be elements of V, unless it is explicitly stated otherwise. 

tag != parse-like-typing
tag == type-reference
type-reference == type
Thus: tag == type
type == parse-like-typing (in colloquial-speak, or "contains")
Thus:
tag == parse-like-typing  (contradicts 1st)
. 
Compile time:
type is determined by parsing source code during LexicalAnalysis
type-reference refers to type
type-reference is associated with value
Run time:
type is determined by parsing values using cfArgument, isNumeric(), etc.
. 

Literals and their types are identified by parsing source code.  Each literal is turned into a value with a reference to its type.
Values of other types may be identified by parsing strings using cfArgument, isNumeric(), etc.
. 
The interpreter identifies the type of each literal by parsing the source code.  Each literal is turned into a value with a reference to its type.
If a string contains a literal, its type may be verified by parsing the string using cfArgument (ColdFusion), is_numeric() (PHP), etc.
. 
For each literal in the source code, the interpreter determines its type and internally converts it to a value with a reference to its type.
If a string contains a literal, the literal's type may be verified using cfArgument (ColdFusion), is_numeric() (PHP), etc.
. 
For each literal in the source code, the interpreter determines its type and internally converts it to a value with a reference to its type.
The type of a literal which is encoded in a string can be verified using cfArgument (ColdFusion), is_numeric() (PHP), etc.
. 
For each literal in the source code, the interpreter determines its type and internally converts it to a value with a reference to its type.
Strings can be checked to see if they represent literals of specified types using cfArgument (ColdFusion), is_numeric() (PHP), etc.
. 
The interpreter converts literals in the source code to values, where each value has a reference to its type.
Strings can be checked to see if they represent literals of specified types using cfArgument (ColdFusion), is_numeric() (PHP), etc.
. 
The interpreter converts literals in the source code to values, where each value has a reference to its type.
Values with a reference to the "string" type -- i.e., values of type string aka "strings" -- can be checked to 
see if they contain a sequence of characters that represents a literal of a specified type, 
using functions like cfArgument (ColdFusion), is_numeric() (PHP), etc.
.
  1. Let S be a character sequence, which is an ordered collection of characters from a character set
  2. Let T be a type, which is defined here to be a set of character sequences T = {S1 .. Sn}
  3. Axiom: For every S, there exists at least one type T such that S ∈ T, or S is considered invalid 
i.e., every valid S is an element of at least one T
  1. Let V be a value, defined as V = (S, T) such that S ∈ T
  2. Let C be source code for a program, which contains character sequences S1 .. Sn
  3. Let M be the computer memory in which a program C runs
  4. Then, for every Si in C, the interpreter finds a T where Si ∈ T and converts Si to a value Vi in M such that Vi(T) = T and Vi(S) = Si
  5. Then, given a value V(S, T) in M and a type T, program C can determine if V(T) = T or V(S) ∈ T
.
  1. Let S be a character sequence, which is an ordered collection of characters from a character set
  2. Let T be a type, which is defined here to be a set of character sequences T = {S1 .. Sn}
  3. Axiom: For every S, there exists at least one type T such that S ∈ T, or S is considered invalid 
i.e., every valid S is an element of at least one T
  1. Let V be a value, defined as V = (S)
  2. Let C be source code for a program, which contains character sequences S1 .. Sn
  3. Let M be the computer memory in which a program C runs
  4. Then, for every Si in C, the interpreter converts Si to a value Vi in M such that Vi(S) = Si
  5. Then, given a value V(S) in M and a type T, program C can determine if V(S) ∈ T
. An "association" then exists similar to what one would find in a relational schema. Then if the code "executes" a function such as isNumeric, CF would do a lookup in such tables. Granted, it's not a resource-efficient way to implement isNumeric and similar operations, but technically would work. Look-ups (set membership) can often be traded for computation (such as parsing) and vice verse in implementations such that it's not a distinguishing feature, or at least not a reliable feature to tie models and language descriptions/manuals to. Relationships can be "stored" or calculated/computed as needed and the decision of choice is often a matter of resource efficiency, not a feature of what the I/O looks like (observable behavior to the programmer).

That is true. As implementation strategies, the above are certainly feasible, and you're right that parsing is not a distinguishing feature.

And that kind of "associated with" (parsing like) often behaves different than the tag kind of "associated with", and "associated with" alone does not distinguish between the two. For one, there is one and only one association in the tag flavor with the variable, and the model makes that clear via a data structure (XML) that makes quantity limits clear and instantly perceptible to the reader.

In the phrase "x is associated with y", it means that given x, you know y or can answer questions about y. If the relational model appeals to you, imagine that x is the primary key and y is an attribute value. Whether y (meaning a type, in this case) is "parsing like" or "the tag kind" (?) is irrelevant, except where explicitly stated as I have done in TypeSystemCategoriesInImperativeLanguages.

If the phrase "a variable is associated with a type" is used, you can safely assume that any distinction between "parsed" vs "tagged" or whatever is irrelevant, and the only important factor is that a variable is -- somehow, and we don't care how -- associated with a type.

By "instantly perceptible", I mean they don't have to remember that rule from 20 pages back; it's still there, visually presented in the key data structure(s) of the model. If one has a photographic memory, than such "rules" stated in English are sufficient. But a good many developers don't have photographic memories such that a quantity rule like that is best represented in something more visual or easier to remember than a buried English rule. My model is to be human-friendly, not machine friendly. Your brain may easily store and catalog bunches of verbal rules like "all zogs are floogs except if the zog has a nib on Thursdays that correspond to gliggs...", but you cannot extrapolate that ability to all humans. A diagram or data structure in a familiar format (XML, relational, etc.) simplifies the absorption and recall of such rules, associations, scope ties, and quantity limitations.

--top

Obviously, there's nothing wrong with diagrams and illustrations, but the verbal explanations on TypeSystemCategoriesInImperativeLanguages are equivalent. If they don't appeal to you, that's fine. Feel free not to read them. Note that TypeSystemCategoriesInImperativeLanguages includes ASCII diagrams and XML for those who prefer them.

It lacks the "mechanical" links between the text and diagrams, per above.

What do you mean?

[Verbal descriptions deemed "equivalent" is like saying that a verbal description of a real landscape is "equivalent" to the landscape (or a picture thereof) itself. Not likely.]

Of course not, but if I describe a blue square inside a green circle, and draw the same, then my verbal description and my diagram are equivalent -- at least in the salient details. That is what was meant by "equivalent", above.

Consider:

[1] An example of an objective statement about terminology and syntax could resemble, "Out of the top 100 most popular languages, 85% call the following syntactic pattern [insert RegEx here] a 'foo', per their published syntax diagrams."

Notably, out of the 10 most popular imperative programming languages as of this writing (per the TiobeIndex: C, Java, Objective-C, C++, C#, Basic, PHP, Python, Perl, and Delphi), 100% have the same syntax for assigning a value to a variable bar the symbol used for assignment (it's ':=' in Delphi, '=' in the others) with semantics as described in TypeSystemCategoriesInImperativeLanguages.

In rough sense, above the level of the our disputed areas, I agree.

Related evidence discussion at CertaintyIsaSmell.

Basis: WhatIsSemantics

See also: VagueOrArbitrary

OctoberThirteen

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