Continued from ValueExistenceProofThree.

------
The issue with "TTM" and a local acronym shortcut for TopsTagModelTwo has been moved below.
-----
I'm curious, what do you find wrong about this train of logic for "typical" dynamic languages (at least "D1" per TypeSystemCategoriesInImperativeLanguages)?

* 1. Given: All expressions have or return a type (at least one).
* 2. Given: Variables can serve as expressions.
* 3. Therefore: Variables have or return a type.

More explicitly:

* 1. Given: All expressions have or return a type (at least one).
* 2. Given: Variables belong to the category of "expressions". 
* 3. Therefore: Variables inherit the features of "expressions". (Category feature inheritance rule and #2)
* 4. Having or returning a type is a feature of the category "expressions". (Restatement of #1.)
* 5. Therefore: Variables have or return a type because they belong to the category of "expression".

Note that I'm not making a distinction between "have" and "returned" because that's a "store" versus "compute" issue, which may an implementation-specific decision. If you disagree, please elaborate. 

--top

''A variable isn't an expression, so "variables can serve as expressions" isn't quite accurate, but an expression can consist only of a reference to a variable.  As per elementary algebra, in an expression a reference to a variable always (and only) means "the variable's value".''

''Note that popular imperative dynamically-typed programming languages either require variables to be initialised (i.e., explicitly assigned a value) or they have a default value (i.e., implicitly assigned a value).  Thus, a variable is only meaningful if it has a value.  Note that there is no language semantic, in any popular imperative dynamically-typed programming language, that makes reference to a variable's type independent of its value.  Note also that there is no language semantic, in any popular imperative dynamically-typed programming language, in which the type of a reference to a variable is anything but the type of the value most recently assigned to that variable.  Thus, in popular imperative dynamically-typed programming languages, a "variable's type" is a meaningless though sometimes convenient human-language shorthand for "a variable's value's type".  Only "a variable's value's type" is meaningful.'' 

Regardless of your long winded pontification, your point is in-correct. Variables (named or otherwise) are given a memory location and that location depends on the length of the variable (type) unless it is a reference (pointer) to other kinds of data. To be useful at the moment of reference in an executing program, the variable must have a type and a value. At this moment in time, the variable, it's type and it's value are equally related. I would even argue that a value isn't married to a specific type. In my language, I do automatic conversions so that a '5' stored in an integer is treated exactly like a '5' stored in a double floating point number. The type of a variable defines it's length, format and in my language, the set of functions that can be used on it. Just because you can change the type of a PHP variable within a function by just assigning a different value type to it, doesn't mean that "type" only refers to the value and not to the variable. That is just incorrect! -- DavidClarkd

''In most languages, values to be stored in a variable are given a memory location, of a size dependent on the type of the value.  In a typical DynamicallyTyped language -- i.e., a language where variables are untyped -- the variable is typically represented as a pointer to the memory location containing its value. (Of course, a pointer is also a value in memory -- of type 'pointer'!)  The fact that you can assign any value of any type at any time to a PHP variable '''does''' mean "type" refers only the value associated with the variable, and not to some "type" property of the variable itself.''

Would it be possible to express yourself by offering your opinion rather than implying that you are stating facts. You aren't! If the pointer doesn't also have type information, then the type would have to be stored with every instance of that variable. So a vector with 1 million elements has it's type repeated 1 million times? If this is correct, why would anyone design such a fatally flawed language? Can you imagine a database file that repeats that name of every field on every row? I don't know for sure what internal representation PHP uses but I know that at the moment of referring to a variable at execution time, the name, type and value of a variable are equally related or you get an error. What happens before this reference isn't important except from an efficiency point of view. Just my humble opinion, oh great one. -- DavidClarkd

''Actually, I am stating facts.  I've been discussing scalar values, as has been done throughout the V''''''alueExistenceProof<x> series of pages.  In some DynamicallyTyped languages, array storage may be optimised as a structure with a single type reference paired with a collection of value representations, but many DynamicallyTyped languages (PHP, for example) allow arrays to be of mixed types.  Thus, a vector with 1 million elements that are all the same type will, in fact, have its type repeated 1 million times.  This, however, means it is possible -- and legitimate, I suppose -- to have a vector with 1 million elements in which 999,999 of them are boolean, but one of them is a string.''

(See "Types and Arrays Example 1" below for an illustration of the vector issue, using the conventions of parent topics. -t)

''Yes, your illustrations reflect real implementations.''

Both are legitimate possible implementation or feature approaches in dynamic languages, but according to you, using (implementing) the "factored" version would violate some universal rule of value-ness because allegedly "type indicators MUST be stored directly with the value representation" as some kind of universal "rule of math" (both paraphrased). That would mean this odd law would force inefficiency on language/interpreter designers in order be compliant. (I haven't surveyed what existing common dynamic languages actually allow.) -t

''I've never claimed that "type indicators MUST be stored directly with the value representation".  What I claim is that a value is a representation '''associated with''' a type.  In the "factored" version, every representation '''is''' associated with a type, such that every array element unambiguously references a value.''

In my model, the "value" (or "representation") ''is'' "associated with a type" also. Yet you complained. "Associated with" used in normal English does NOT dictate/limit nesting level (or lack of) nor a specific data structure organization nor levels of indirection for the association. All it requires is that ''some'' known association exists. There can be 10,000,000,000 links/levels between two parts/objects, but they are still "associated with" each other. Any level/depth/distance/design restriction you propose on the phrase "associated with" is purely an artifact of your personal preference/interpretation, barring sufficient documented literature phraseology analysis. (Granted, it may be a continuous concept in practice instead of discrete, but that doesn't improve the usability of your usage of the phrase in any known way.) -t

''I don't recall what my specific complaint was, but I must have found it unclear that a representation always has an associated type.  If every representation has an associated type, that's good.''

Whether it "always" has an associated type indicator, I don't know. It may depend on the language operators. But the usual configuration in the model has the type indicator attribute in the same tag (record) with the value (AKA representation). That layout is usually considered "associated with" in colloquial English. At least in my country. Maybe The Brits use it differently? DB Example:

  table: Families
  --------------
  family_ID
  family_sir_name   // ex: "Smith"
  father_SSN
  mother_SSN
  children_ref   // foreign key to Children table 
In this table structure, a given father (father_SSN) is considered "associated with" a mother (mother_SSN). Do you agree with that English usage? Do you agree that such a table "associates a father and a mother"?

''Certainly, father_SSN and mother_SSN are associated with each other, by virtue of both being (presumably) functionally dependent on family_ID.  A representation always has an associated type indicator, because without it the representation is a meaningless sequence of bits.  Here's an example: 101010101010110111010111010110110.  What is it?  Without an associated type, you can't know.''

I don't see disagreement in your response (although it appears to be wondering), so I assume you are agreeing that in TTM, "a value is associated with a type" in the same way that "father_SSN and mother_SSN are associated with each other", your own words.

''I can't tell.  It appears representations (which you call values) and types are manipulated independently, making it difficult to determine whether or not a representation is always associated with a type.''

* Manipulation and association are generally orthogonal. For example, my teeth are clearly associated with my gums (as long as somebody doesn't punch me in the face over HOF's or something). However, my teeth and/or gums can still be manipulated independently by a dentist.

* ''Be that as it may, it's difficult to tell whether or not your model always pairs a type with a representation.''

* No it isn't, the data structure is shown up front and one can see that the type indicator is in the same XML tag as the "representation".

* ''Historically, your model has relied on certain attributes being able to be empty or null.  Thus, by your own modelling conventions, the presence of a type reference attribute in the same XML tag as the representation attribute does not, in and of itself, indicate that a type reference is always associated with a representation.  The representation, or the type reference, could be null.''

* PageAnchor: null-738

* Whether it's required or not '''depends on the language''' being modeled. In most of the languages I've tested, "null" doesn't have a detectable type, but I don't want to hard-wire such universally into the model because there may be dynamic languages in which nulls do have a detectable type. (There are different ways to implement null's. It's something I haven't addressed in the model writeup, I will admit.)

* ''I'm not talking about implementing null values in a programming language -- that's trivial -- I'm talking about your use of nulls '''inside''' your model.''

* I'm not clear on what your concern is specifically. If it doesn't affect IoProfile and is a minor design-preference issue, then add it to your personal copy of the model. No harm no foul.

* ''My concern is that despite your claim that your model does always pair a type reference with a representation -- necessary, otherwise the representation is meaningless -- if you use nulls in your model, how do we know you haven't "nulled" out the type reference, thus resulting in a meaningless representation?''

* Well, perhaps if nulls don't need a type indicator, then we can make an exception to an "always paired" rule. Again, there are different ways to implement nulls (both for the same behavior, and for different behavior of nulls). 

* ''Again, I'm not talking about implementing null values in a programming language, or how your model deals with null values in a programming language that it models.  I'm talking about your apparent use of nulls within the pseudocode that constitutes part of your model.  Does it make it possible to manipulate a representation without an associated type?''

* I'm sorry, I have no idea whatsoever what you are talking about. 

* ''You've claimed that your model always associates a type with a representation, because the same structure has both a "type" attribute and a "representation" attribute.  Historically, you've also indicated that your structures have multiple roles; for certain roles, certain attributes may be unused.  Because of that, the mere presence of attributes within a structure does not guarantee that all the attributes are used.  Therefore, it is conceivable that there are cases where even though a structure contains both "type" and "representation" attributes, one of them may be unused.  Is that the case?''

* What do you mean by "unused"? If a given language doesn't use them (acts like it doesn't use them), then it makes sense a model may not also.

* ''By "unused", I mean "not set to any value such that it's empty or null, or explicitly set to empty or null."  Can you give an example of a language where a representation does not have an explicit or implicit type reference, or vice versa?  I.e., where it "acts like it doesn't use them"?''

* I'm sorry, I have no idea whatsoever what you are talking about. Do you have a code snippet we can walk through or something more concrete or specific?

* ''Is there an example of a language where a value's representation is not always paired with an implicit or explicit type reference?  I don't know what code snippet would make it more specific, because I don't know of any language where a value's representation is not always paired with an implicit or explicit type reference.''

* I don't know, I have not examined all dynamic languages. It's '''feasible that nulls could be implemented/modeled via an empty and/or missing attribute for a given language. I'm not ruling it out''' at this point. -t

* ''Null is the only value of type null in some languages, an alias for integer 0 in others.  Thus, it too has a representation and a type.''

* You are dictating a '''specific''' implementation. I can see at least 3 different ways to model (typical) nulls that match such languages' behavior. It again appears as if you are mistaking your personal internal head notions/interpretations for universal truths.

* ''Could you describe the three different ways to model (typical) nulls?''

* Do we really want to get into that? I want to make sure it's relevant before going down that path. I smell a long sub-debate over nulls where we do the LaynesLaw dance over the meaning of "null". For '''non'''-nulls, both attributes are always populated in the model with the contentious name. (Zero length strings will result in a zero length attribute value or "representation".)

* ''I think it might be worth discussing, and relevant.  I would argue that nulls -- assuming they're treated as values -- still require a type (which could be type 'null' and a representation, though if the type is 'null', the representation may be implicit rather than explicit.)  A zero-length string, of course, has a type (string) and representation -- a zero byte (or word) representing either a null termination or a zero length, usually.''

* "Might be" worth it? No thanks. If you can find solid documentation/proof that nulls MUST be implemented a certain way, provide it first. (I don't want your personal interpretation of such documents, I want to see explicit rules.)

* ''I never said nulls must be implemented a certain way.  There are many ways to implement nulls.  However, a null implemented as a value has a type (possibly type 'null') and a representation (which may be implicit if it's type 'null').''

* Please elaborate on the last sentence. Is that a rule? If so, where does it come from?

* ''It's a logically inevitable result of implementing imperative programming languages on computational platforms.  For every value, in order to interpret its representation there must be a type, and for a particular value to be uniquely identified, there must be a representation.  If you can find another way to implement values and still have them work in languages where values are used -- i.e., as arguments, function results, variable contents, what literals denote, what expressions evaluate to, etc. -- please describe it.''

* None of that contradicts said model, at least as I interpret English.

Actually, the off-topic second sentence is '''false''', by the way. A print/write statement could potentially export/dump the value/representation, '''stripping off the type indicator'''. A toString() function may do the same. 

''No, it's true.  A print/write statement in typical languages does not emit a value's representation directly.  In most languages, emitting a representation directly via print/write would result in a splat of meaningless characters on the console screen.  Instead, what actually happens inside print/write is the type associated with the representation is used to determine how the representation should be emitted.  For example, an integer representation -- typically binary, using anywhere from two to eight bytes -- will be converted to the sequence of ASCII or unicode characters that denotes its value.  In other words, a value's representation is emitted as a literal that denotes the value.  Character strings are often represented in a manner that can be emitted with minimal conversion, but even character strings usually have to be processed slightly, because most character strings are represented with a length preceding the characters, or a zero byte indicating the end of the string.  When such a representation is emitted, the length or zero byte must be omitted.''

It's true the type indicator may ''affect'' the final output of "Write" or "toString", but the type indicator itself is rarely included in the output. Thus, your statement as given, "A representation always has an associated type indicator" is false. That is unless you interpret "has" to also include "influenced by", which is a really big stretch of English in my book. -t

''I'm referring to values' representations, not representations in general.  Once emitted as a literal, it's no longer a value within the language.  However, literals generally '''do''' have a type "indicator" -- the characteristics of their character sequences.  Integer numeric values are limited to certain characters -- digits -- optionally prefixed by + or -.  Floating point numeric values extend integer numerics with a single E and/or '.'  Strings are typically limited to printable ASCII codes or unicode characters, and are often delimited by quotes.  Dates often consist of three sequences of digits of limited ranges, separated by '/' and sometimes '-', or the presence of three-character date codes in a specific syntax.  And so on.  It is precisely these characteristics that allow language parsers to successfully perform lexical analysis on literals -- i.e., recognise them -- in order to determine their types.''

I thought it was intended as a ''general'' rule ("common notions/semantics") and not specific to computer languages. If it's a rule specific to computer languages, who or what is making this rule and why should we listen to them in terms of our modelling?

''To what, outside of computer languages, would this rule apply?  Within computer languages, no one individual or agency is making this "rule".  It's simply an inevitable, logical outcome of computer architecture and making workable computer languages that run on that architecture.''

No, it's not "inevitable". D2 languages don't have an '''explicit''' association with a "type". And "implicit" happens in the head, but I'm not modeling heads.

''Indeed, as I wrote on TypeSystemCategoriesInImperativeLanguages, D2 languages have an implicit association with type "string", but it doesn't happen "in the head", it happens in how every operator that accepts a value must be written -- they must be written assuming all representations are strings.  The language used to implement the interpreter or compiler will often do this simply by making the representation be type 'string' in the implementation language.  For example, if you're writing an interpreter for a Category D2 language called "foo", you might implement it in C with the value representation being defined as type 'char *'.''

(PageAnchor indirect_types)

In D2 languages one can have "dates" and "numbers" which are not explicitly tracked as such. They are typically parsed by a given operator to see if they "can be interpreted as". The "association" of the variable/object/value with "date" or "number" is very indirect, if it can even be called an association. (I really hate the word "associate" when rigor is needed. It's just too damned fuzzy.)

''In any language, one can have "dates" and "numbers" which are not explicitly tracked as such.  That isn't characteristic of Category D2 languages, though Category D2 languages rely on it.  What is characteristic of Category D2 languages is that all values are of type 'string'.  That's why Category D2 languages are sometimes called "string-typed" languages.  Such values may contain '''literals''' denoting values of other types.  Literals frequently identify their type in the characteristic of their character sequences.  For example, an integer literal consists strictly of numeric characters.''

Re: "...is that all values are of type 'string'". Nope! Internally they could be zibblenoffs. That's a specific implementation decision. For example, as I've pointed out before D2 languages (or languages with a D2 IoProfile) could internally "compress" digit-filled strings as numeric and internally mark them as such. If a later operator wanted to do numeric things on that object, the internal implementation may recognize it's compressed as a number and knows to skip conversion from string to a number. But this is merely an efficiency decision and does '''not affect what the programmer sees''', similar to caching. The fact that such compression occurred would not be detectable by the programmer (outside of machine performance analysis). In short, you are unnecessarily dictating implementation.
 
''Internally they could be represented as zibblenoffs, but an observer would inevitably call them strings and unless the language leaks zibblenoffs somewhere, their representation is opaque.''

But that's not how you are defining D2. Further, an observer might call them "numbers" or "dates", not strings.

''That is how I am defining Category D2, though I could have been more explicit about "[E]very value is represented by a string of characters" and written "every value appears to be represented by a string of characters".  An observer might call them "numbers" or "dates" until they do a typical test like $p="234"; echo getType($p); that leaks an implementation (i.e., language category) hint.  (Quiz: what would a Category D1 language emit? How about Category D2?)  Of course, it is possible to design a language that provides no hint as to whether it is Category D1 or Category D2.''

The D2 languages I know don't have a getType() equivalent.

''Do you think that's a defining characteristic of Category D2 languages?''

If one needs to model a type tag (indicator) to model built-in functions such as "getType()", then its existence would indeed imply a D1 language. A least one operator needs the existence of a tag-like thing to explain its behavior.

''What if the result of '$p="234"; echo getType($p);' is "integer"?''

That's not "getType" as say Php "does" it. I'd need more experiments to propose a model. That one experiment does not distinguish between model possibilities. Initially it looks like your version should be called "guessType" in that it does parse-like analysis to guess.

''Imagine a language -- perhaps otherwise just like PHP, but with a getType() exactly as I've described it.  What then?''

Again that's one test. I cannot make any decent conclusions based on that one test. This implementation would match your single test:
 
  function getType($p) {return "integer";}

A more thorough test set would look something like:

  $p="234";echo(getType($p));
  $p=234;echo(getType($p));
  $p=234/345;echo(getType($p));
  $p="234/345";echo(getType($p));
  $p="abc";echo(getType($p));
  $p="234abc";echo(getType($p));
  $p="1/2/2003";echo(getType($p));

''What if the above prints the following?''

 number
 number
 number
 number
 string
 string
 date

I'd tentatively conclude it's doing some kind of parsing to "guess" the intended type. I generally don't encounter built-in functions like that such that I'm not sure what the purpose of it is. Often there are functions like Php's "is_number" that will tell you if a value can be interpreted as a number, but that's a yes/no kind of result, typically used for input validation.

. . . . . . .

[Some people are tired of the way -top debates and this person arguing with -top, is obviously one of them. The person, however, is either stupid or just arguing for the sake of arguing. I am the author of a new language and it makes a lot of sense in my language to give a variable a "type" (without a value) so that the proper value can be assigned to it (contrary to what he said below). By knowing the "type" first, I also then know what functions can be used on that value. If a variable has no purpose without a "value", then why would so many programmers put up with the "null" values in RDBMS? Does it matter if no value has been assigned to a variable (obviously it matters to many programmers)?]

* {What makes you think that "null" isn't a value? Also, you appear to be implementing what would be termed a StaticallyTyped language. This particular debate is in the context of dynamically typed programming languages.}

* [You are wrong on both accounts. If a "null" was a value then there would be a "hole" in the set of values you could store. A "null" is implemented using a flag that would be associated with the variable like it's type. Second, my language has types as dynamic as the most dynamic languages. I allow references (at compile time) to variables that don't exist and I allow calling functions without any restriction on the number or type of parameters (more type checking at compile time is an option). -- DavidClarkd]

* {That's certainly one way of implementing a null value, another way is to use a special sequence of bits (as is done in typical implementations of C) to represent the null value. Either way, it's still a value.}

* ''You're conflating the abstraction with the implementation.  A "hole" might be an implementation issue, but it certainly isn't a theoretical one.  If your variables are typed, that's fine.  The debates that spawned this page have been explicitly about "'''popular''' imperative dynamically-typed programming languages" (see that phrase above, and elsewhere), none of which have typed variables.  If your dynamically-typed programming language has typed variables, that's perfectly reasonable, but your language's variables presumably have different semantics from the variables in (say) Python and PHP.''

* If somebody made a PHP interpreter using the directly-inside-variable approach, '''no programmer would know the difference''' (or at least stop calling it "PHP"). And it would not objectively contradict the existing PHP documentation in any known way[1]. Thus, the "semantics" has not changed, only implementation. (I'll stick to scalar implementation here for now to keep the discussion simpler.) -t

* ''I'm sure someone could make a PHP interpreter in which variables have an explicit scalar type property, but I suspect code analysis would demonstrate it's never used.  The semantics of the PHP language -- claims in the dire manual notwithstanding -- do not make reference to any scalar type property of variables, explicitly or otherwise.  Like all the other popular imperative DynamicallyTyped programming languages, scalar PHP variables support two and only two operations -- retrieve a value, and store a value -- and it is the scalar values that are typed.''

* El Wrongo! You are making up "semantics" characteristics out of the blue. If the internal implementation/structure was changed, the IoProfile would NOT change. The existing operations would act just as they did before (same results) and programmers wouldn't know the difference, and thus there would be no change in observable "semantics" from the app programmer's perspective. In fact, who knows, maybe Php actually does such; we can't tell without inside info about implementation details. '''No app-programmer-side operation would definitely distinguish between the two models''' of scalars. (Memory usage studies could possibly, but that's very indirect.) You again appear to be mistaking your personal mental view/model/preference for external truths.

* ''No, I'm simply rephrasing the documented and observed semantics of the PHP language.  I can find no evidence that demonstrates the existence of a scalar "type" attribute of a variable.  I find considerable evidence that there is a scalar "type" attribute associated with every value, and I find considerable evidence that a variable is a time-varying reference to a value.  Therefore, I conclude that semantically, variables do not have a scalar "type" attribute.  If such an attribute exists for some internal purpose, that's fine -- it's an implementation concern, not a semantic one, and therefore irrelevant.''

* You have not presented the specific text in the manual that reinforces one model over the other. In past attempts to extract such details from you, it appears you read with a biased eye, and interpret English to mean what ''you'' want it to mean. I don't expect a different result if I ask for such evidence again. We just interpret English very different for some very odd reason. I don't know what say other then LetTheReaderDecide which interpretation is correct or most common at each specific quote instance. (In general, if rigor is needed, English is NOT TheRightToolForTheJob. But it's what manuals use for good or bad, along with code-plus-I/O examples, such that we are stuck with it if one wants to use manuals as the canon, which I don't.) -t

* ''Ok, let's try a different approach:  Can you create a PHP code snippet to demonstrate that a PHP variable has a scalar type attribute, distinct from retrieving the type of the value referenced by that variable?''

* No. As I have explained many times, observations of IoProfile show that '''BOTH models work''' in terms of matching the behavior of the languages. No results-based experiment (code snippet) found favors one model over the other.

* ''If the two models are otherwise identical, what is the point of having a redundant and un-used "type" attribute associated with variables, if it has no semantic role?''

* There is no redundancy in the model's key data structure as it's described. If you saw redundancy, you read it wrong. And "semantic role" appear to be made up notions in your head. I think you have hallucinations and need to see a doctor. Serious. '''Languages manuals rarely limit, constrain, or dictate implementation data structures for variables and objects''' beyond being able to do what's needed to get the job done. Those are generally implementation issues and can change on the next release or a competitor vendor's version. Smart manual writers do not dictate implementation.

* ''There's certainly redundancy if you have a type attribute that's never used.  Regarding the semantics, here's another way of looking at it, which to avoid indentation issues, I shall out-dent below:''

** Never used? Please explain. We are talking about D1 type languages, not D2.

** ''Yes, if a variable has a scalar type attribute in a D1 '''or''' D2 language, it will never be used.  That's because all the scalar type information that's ever needed comes from the value contained in the variable.  There's never a need to obtain scalar type information from a variable that is distinct from the type of the value that is in the variable.''

** That's based on YOUR preferred model/definition of "value". I don't accept it as a canon without better evidence.

** ''Canonical or not, it is the most parsimonious approach.''

** That's a different claim. Even if it was true, being non-parsimonious does NOT make the model "wrong". And to me, my non-nested structure is more parsimonious than the nested version. 97.347% of all Vulcans agree that "V(T,R)" is "more parsimonious" than "V(L(T,R))" unless you need to frequently process L's by themselves, which my model doesn't. (V=variable, L=value, T=type-indicator, R=representation, per mostly your term usage. Send me a check for $150 if you want a copy of my official Vulcan survey.)

** ''I think your Vulcans would agree, however, that V(L) and L(T,R) is more parsimonious than V(T,R) and L(T,R), but I suspect the same Vulcans would wonder where the "name" attribute of V appears, and they'd suggest that you '''should''' process Ls by themselves, to represent what expressions evaluate to and what functions return.''

** It depends on how often instances of such occur or are used in the model. I'm not going to put stuff in just to satisfy a strange itch of yours to group things a certain way. I've considered a design with the nesting and a design without, and in my judgment, without is more parsimonious. If your judgement differs, so be it. LetTheReaderDecide. I'm tired of bickering about that.

''Imagine the following PHP snippets, all of which reference a scalar variable $p.  In each case, the semantics of the use of $p are described in a comment:''

 echo $p;                 // retrieve the value in variable p
 echo $p + 3;             // retrieve the value in variable p
 echo gettype($p);        // retrieve the value in variable p
 echo gettype($p + 3);    // retrieve the value in variable p
 $p = 3;                  // store a value in variable p
''Notably, '''every''' operation you can perform on variable p will either be "retrieve the value" or "store a value".  Can you find an operator or mechanism in PHP that requires "retrieve the type of variable p" or "store the type of variable p"?  Note that even settype($p, "bool") appears to be a shorthand for retrieving the value in p, converting it to a value of the specified type, and storing the resulting value in p.''

''Note as well that my trivial "Sili" interpreter (see http://shark.armchair.mb.ca/~dave/Sili) does not have a "type" attribute associated with variables.  At run-time, a variable is a reference to a Value, where each Value has a Type attribute.  Sili's semantics, regarding variables, values and types, is equivalent to popular imperative DynamicallyTyped programming languages like PHP, Python, Javascript, etc.  If I can dispense with a scalar 'type' attribute for variables, don't you think PHP, Python, Javascript and so on can dispense with it too?''

The English versions you give of such actions are '''purely your personal preference''' and may not reflect a canonical way to describe such. I do not accept them as a canon without some kind of rigorous public phrase usage or impression studies. Again, it strongly appears as if you are mistaking your preferred internal mental notions as universal truths.

''Purely my personal preference?  Really?  How would you describe the semantics of the following, vis-a-vis variable p?  Please replace the ???s with your interpretation of the relevant semantics.''
 echo $p;                 // ???
 echo $p + 3;             // ???
 echo gettype($p);        // ???
 echo gettype($p + 3);    // ???
 $p = 3;                  // ???

 // MY REPLY -top
 echo $p; // Display the contents of variable "$p" as interpreted by the "echo" operation
 echo $p + 3; // Display the results of the expression "$p+3" as interpreted by the "echo" operation
 echo gettype($p); // Dislplay the name of the type indicator of variable $p is interpreted by the gettype operation and the echo operation.
 echo gettype($p + 3); // Display the name of the type indicator for the results of the expression "$p+3" as interpreted by the gettype operation and the "echo" operation.
 $p = 3; // Store a copy of the literal "3" or its equivalent in variable $p. [updated.]
 // Note: I do NOT claim these interpretations are canonical. And often short-hand
 // descriptions are used in practice, but are not intended to be rigorous.
''Excellent.  Now, could you do just one more:''
 echo gettype(3);         // ????
* "Display the name of the type indicator of the literal "3" as interpreted by the gettype operation and the "echo" operation". -t

* ''So, in other words, 3 has a representation and a type, and $p has a representation and a type, is that correct?''

* The literal "3"? I'm not sure I'd use the word "has". The assignment process typically "extracts" a type using various syntax rules. Thus, one could consider that a computed result, which "has" is generally ''not'' used for, although, that's only a rough pattern of English usage. You are asking me to apply English in ways it's not fully appropriate for. For our purposes, we could probably say "it has one explicit type, as determinable via the language's syntax rules" (in D1-like languages).

* ''No, I don't mean the literal "3".  I mean its value, or what you call (above) the "equivalent" in "the literal '3' or its equivalent".''

* "Value" is an implementation detail, or sometimes another way to say "unspecified content".

* ''No, "value" is an abstraction of any specific value.  As for it being an "implementation detail", does that mean values in arithmetic and algebra are an "implementation detail" there, too?''

* Values are an abstraction of values? 

* ''No, the term "value" is an abstraction of any specific value like 3, 1.1415926, or "fish".  The literals in the preceding sentence denote "values".  Each one denotes a "value".''

* And "mean" is in the head, not a feature that exists outside of human heads.

* ''Here, that is a non-sequitur comment.''

* '''If math rules clearly dictate that values, variables, etc. have certain properties that affect our models, please cite such rules.''' (I don't want your personal opinion/interpretation, I want the ''actual'' written rules.)

* ''The fundamental factors have been axiomatic to basic arithmetic (numbers) and algebra since before the dawn of recorded history, though this (randomly chosen) source is as good as any: http://cs.gmu.edu/cne/modules/dau/algebra/basicarith/arith2_frm.html -- "An expression is a string of values and operators to be evaluated", etc.  The correspondence between this and computational implementations of it -- noting that computers exist because we humans wanted machines to perform arithmetic and elementary algebraic calculations -- is obvious.  The rest derives inevitably.  A value requires a representation in order for it to exist in a computational device, a value requires a type are in order to identify the appropriate operations to perform on the representation, a variable is a time-varying reference to a value, a literal is a sequence of symbols that denotes a value, and so on.  Simple stuff.''

* TTM2 does NOT contradict any of that, at least as I interpret that English paragraph. The type tag is right there next to the value/representation for any operation to make use of it as it sees fit. Further, the link you give says nothing about types. Actually, D2 languages don't require an explicit type. So are the math police going to throw such languages in jail? 

* ''As I've pointed out in TypeSystemCategoriesInImperativeLanguages, in languages where all values have the same type (language category D2), the type can be implicit.  If we know a value's 'type' attribute will always be "string", we can dispense with an explicit 'type' attribute.  Likewise, we generally do not consider "types" in basic arithmetic and elementary algebra, because we're always dealing with numerical values -- i.e., they're implicitly all the same type -- though occasionally we do consider the differences between integers, rational, and irrational numbers.  Then we're explicitly dealing with different types, even though we rarely use the term "type" in basic arithmetic and elementary algebra.''

* What was your reason for including that hyperlink if it says nothing about types?

* ''We weren't discussing types.  This whole set of pages is, you will recall, about a '''Value'''E''''''xistenceProof, not a '''Type'''E''''''xistenceProof.  It was in response to your request (above) that, "if math rules clearly dictate that values, variables, etc. have certain properties that affect our models, please cite such rules."  You didn't mention types.  That said, in the paragraph to which you responded I addressed types in mathematics to the extent that they're relevant here, and I will add that "types" in mathematics (outside of, e.g., TypeTheory and ComputerScience) are often represented by different branches of mathematics.''

* Well, both models in question have something called "value", so that is not related to the models.

* ''I'm not clear how your response is relevant.''

* I don't know what your link and related statement is relevant to either. I'm talking about the two models. If you want to talk about something outside of the models, I'm not interested today. 

* ''It was in response to your request (above) that, "if math rules clearly dictate that values, variables, etc. have certain properties that affect our models, please cite such rules."  I cited a reference to basic mathematics, which inherently provides the "rules" upon which imperative programming languages -- at least, expression evaluation and variables -- are based.''

* Which SPECIFIC rule in the link does a model in question CLEARLY violate?

* ''Above, you claimed that "'Value' is an implementation detail, or sometimes another way to say 'unspecified content'."  That does not accord with the link above, or any mathematical convention.  In simple arithmetic, for example, "value" always refers to a number.  I've never seen it refer to "unspecified content".''

* If "value" and "unspecified content" are pretty much synonyms, then most will go with the first because it's shorter and more common. Further, since most arithmetic doesn't deal heavily with types, the relationship between "value" and "type" does not need to be addressed very often and is rarely a practical issue.

* ''"Value" and "unspecified content" are '''not''' synonyms, and types are not part of this particular discussion.  They are, however, crucial to programming language implementation.  Without types, the representation of values in a computer is meaningless.  What is 110101010101011111011011?  Until I specify its type, you cannot know.  Neither can the computer.''

* What's your 110101010101011111011011 example have to do with this sub-topic? I didn't say "toss types".  (Note that it's possible to leave interpretation of a string or "list of bytes" up to the human reader and/or a particular operation/function, perhaps using conventions or context.)

* ''You pointed out that "most arithmetic doesn't deal heavily with types, the relationship between 'value' and 'type' does not need to be addressed very often and is rarely a practical issue".  That's true in arithmetic, where the type of values (numbers, invariably) are recognised immediately by (most) humans.  However, computers '''need''' types to correctly manipulate values '''at all'''.  Even if the interpretation of a value is ultimately only meaningful to a human, the computer still needs to know the type of a "list of bytes" -- even if all it ever does is output it -- in order to output it correctly.  For example, the process for performing output will be different depending on whether the "list of bytes" represents an integer, or a string.  If it's an integer, it's typically a binary representation and so will typically need to be converted to an ASCII or unicode representation before being emitted.  If it's a string, the characters can typically be emitted as-is, but the length prefix or null terminator must be skipped.''

* In D2 languages, the "computer" doesn't have to make any such decisions. It often just coughs out the byte stream as-is.

* ''True, that's because in D2 languages, every value's type is 'string', so the "output" method merely needs to emit a stream of characters.  However, equivalent complexity potentially appears elsewhere.  In D2 languages, for example, numeric addition needs to convert its numeric string operands to binary integers, whilst in D1 languages, the binary integer representations can be added as-is.''

* See PageAnchor indirect_types

Re: "in PHP that requires..." No, it's not "required" because there are at least two different models that can be used to explain it. But it works both ways. I never claimed my tag model or structure was "necessary" to describe/model language behavior (I/O), and that's because there are alternative models. There is no specific result found so far that "breaks" the other model (except maybe for specific languages with unusual features). It's like complaining that my orrery has gears and that gears are not required because threaded sprocket-based spindles could be used instead. While true, that does not make the gear-based orrery any less of a model than the thread-spindle orrery. Why point out that "gears are not required"? Even if true, it doesn't invalidate the model. Your "not required" is a UselessTruth. 

''If it's a truth, "useless" or otherwise, doesn't it make sense to reduce redundancy in order to reduce the likelihood of confusion?''

* What redundancy are you talking about? Please be clear.

* ''The redundancy of having a 'type' attribute of variables that is never used.''

* You read something wrong. It's used.

* ''If it existed in any popular imperative programming language, no, it wouldn't be used.''

* ONLY if your arbitrary model of variables and values was assumed. Fortunately, you are not the God of Implementation and Models, except maybe in your own head. I'm going to go out and buy DavidClarkd's interpreters and burn all of yours in protest of your false canon claims.

* ''Excellent.  I think you'll find DavidClarkd's interpreters on the shelf beside RichardKulisz's BlueAbyss.''

* We suspect YOU to be the new Kuliwz, with your insistent value hallucination skills.

* ''If I'm hallucinating "values", there sure seem to be a lot of language reference manuals and computer architecture texts having the same hallucination.''

* You are hallucinating a specific design/implementation of values. As written, such manuals don't contradict TTM either.

** [I hate to be a grammar-nazi, but that would be "my tag model" or "top's tag model", not "the tag model"] - ChaunceyGardiner

** The context is clear to anybody who's been following these discussions. If you haven't read enough to know what that's referring to, then none of the other stuff nearby will make sense either. -t

** ''I believe ChaunceyGardiner is suggesting that your model be referred to strictly as '''your''' model.  Until it has some traction outside of your own support for it, it does not deserve to be called "the" tag model, as that implies more acceptance of it -- and even recognition of it -- than there actually is.''

** It appears to be quibbling over nothing for the sake of social intimidation or revenge for attacking sacred cows. But I will respect your silly wish and come up with some kind of working acronym. I'll be gradually changing it. Asshats. -t

** ''What "sacred cows" are being "attacked" here?  It's not quibbling, simply a desire for clarity.  Imagine the frustration of a casual reader who encounters "the tag model", reasonably deems it to be something general, and futilely searches for it on the Interwebs.  Describing it as "my tag model" or "Top's Tag Model" clearly gives it either context, or searchability, or both.''

** There are a hundred other things that could trip up a reader walking into the middle, being most of it is casual conversation. Why focus on '''that''' piddly little issue? It clearly looks to me like you are just being a dick as revenge because you ignore so many other potential points of confusion.

*** [Well can we remove at least this one little "trip up" opportunity? There are others which should also be pointed out, but one at a time is fine by me.]

*** What an odd little coincidence you picked that one first.

Both our models have the same basic attributes to be used by the interpreter/model when needed. They are only packaged different in relation to other. The packaging doesn't change what's potentially available to the interpreter/model. Any operation can get whatever attribute it needs when it needs it such that '''packaging choice is not an impediment to processing''' language statements and thus does not affect the observable results of the programming running. The packaging choice only affects the design issues from the "guts", the interpreter/model/engine internals perspective. -t

''However, my model is -- to use a word that I'm glad to see you using -- more parsimonious.''

I doubt that, especially if "soft polymorphism" (SignaturesAndSoftPolymorphism) is taken into account, which I believe it should.

''As noted on SignaturesAndSoftPolymorphism, there is no popular imperative programming language that implements it -- indeed, TutorialDee is the only language I know where it's possible -- so there's no reason why "soft polymorphism" should be taken into account.''

And I countered that viewpoint somewhere (I can't re-find) in that relatively uncommon scripting languages are often bundled with products and tools such that one is fairly likely to encounter relatively low-usage languages in the field.

''It was pointed out at the time that there are no known languages that implement "soft polymorphism" as you've described it, and even if there are, it's merely one of innumerable possible obscure features.  Therefore, it makes no more sense to consider "soft polymorphism" than, say, predicate dispatch or multiple dispatch or logic programming or anything else.''

* D2 languages do it. It seems perfectly plausible to have a D1/D2 hybrid out there. It's true that I have yet to find a specific instance of a hybrid, but I haven't tested nearly enough to rule it out. And the other features you list would not be expected in a "typical" scripting language. To keep the model flexible, I allow each and every operator to do what it wants to with the type indicator and the representation (per your nomenclature), including ignoring one or the other if it so wants. If you disagree with that design decision, so be it. -t

* ''D2 languages do not dispatch operators polymorphically.  In Category D2 languages, all operators take operands of one type -- string -- and there is only one operator implementation per operator name.  Category D2 languages are sometimes called "string typed" languages, because when an operator receives a string as an operand (in Category D2, '''all''' operators receive '''only''' strings as operands), it can parse the string to see if it encodes a literal of a different type, like a date or numeric value.  Of course, all languages can do that, so it isn't a distinguishing characteristic of Category D2 languages.  The only distinguishing characteristic of Category D2 languages is that all values are of type 'string'.''

* "One operator" may be the sticking point. One often cannot tell if it's multiple operators of the same name with different "type" signatures, or a single operator (method) that uses conditionals on the "type indicator" and/or "representation" (parsing), which I nicknamed "soft polymorphism". If one cannot tell, then I'll consider both models/implementations interchangeable.

* ''If "soft polymorphism" is nothing more than an operator doing whatever it likes with its operands, that's nothing special, and it's already covered on TypeSystemCategoriesInImperativeLanguages.'' 

* If that's the case, then BOTH models work. Congrats! (Hard to tell, since that page is poorly written in my opinion.)

* ''I don't know if your model works or not, but I'm not sure that's relevant here.  This threadlet emerged because I claimed that my model is more parsimonious than yours.  You responded with, "I doubt that, especially if 'soft polymorphism' ... is taken into account ..."  How, then, is your model more parsimonious if "soft polymorphism" is taken into account?''

* I doubt parsimony claims can be settled unless a comparable code set can be created, which may not be possible since the "parts" don't map 1 for 1, because different issues will probably piggyback on different related parts, for example.

* ''That may be true, and some metric for "parsimony" would have to be agreed upon.''

* The chance of you and I agreeing on that is exactly 1 in 1,000,000,000.58372, according to C3P0. Thus, I choose to LetTheReaderDecide.

----
[ You simply have no idea what you are talking about. Computers are not theory, they are real. All variables have "types" at execution time. Dynamic or even no type languages just leave the "type" decision to execution time rather than compile time. No typed variables? You are clueless. All PHP variables have a type at execution time. A type defines the format and meaning of a sequence of bytes. If no type, then how could any byte sequence make sense? Some languages say that the "value" has a type and the variable is just associated with the value (the variable itself has no type). This is just weasel words. To refer to a "sequence of bytes at some location", we use a variable name so the name, type, memory location and value are all equally associated. -- DavidClarkd ]

* ''I've been building interpreters and compilers, professionally and for educational purposes, for over thirty years.  So, I do know a wee bit about the subject.  In popular imperative DynamicallyTyped programming languages, a variable is a time-varying reference to a value.  A value has an explicit type -- a type reference -- but a variable does not.  Semantically, in popular imperative DynamicallyTyped programming languages, there are only two operations on variables: retrieve a value given an identifier (or index), and store a value given an identifier (or index).  There is no operation to retrieve or store an explicit "variable's type" because it's unnecessary.  When a variable is used in an expression, the type of the expression is determined from the type of the value referenced by the variable, not from the variable itself.  Of course, there are imperative DynamicallyTyped programming languages where the variables have untyped semantics, but the internal representation of a variable has a type reference for some internal purpose, but that's an implementation detail -- do not conflate the visible model and its semantics with internal optimisations of its implementation.''

* [If you are correct then PHP wouldn't have a group of functions that return whether a variable is an integer, string etc. Functions like is_string(), is_int(), is_real() etc are obviously only in '''my version of PHP''', correct? A variable's type never matters in any of my programs, I just expect the compiler to figure it all out! And while it is at it, it should be able to write the program as well while I am at coffee!  -- DavidClarkd]

* ''Is your sarcasm necessary?  PHP doesn't have a group of functions that return whether or not a variable is an integer, string, etc., despite what the documentation says.  Functions like is_string(), is_int(), etc., return whether or not the value of an expression is an integer, string, etc.  Try it.  is_string("fish") returns true, is_string(true) returns false, etc.  You don't think the PHP folks implement a different version of is_string() just to work with variables, do you?  Of course not.  They have one version of is_string() that accepts a value and returns true if its type is 'string'.''

* More word games. The constant is stored temporarily in a variable and the type of that variable is given. A constant is stored exactly like a variable except that the language makes sure you can't change it. It wouldn't surprise me if you could put an expression in as well and get a result from the temporary variable created from that. Do you really think I don't know? Your comments are so over the top that '''yes''', I do think my sarcasm is justified, as I am telling you nothing you don't already know! -- DavidClarkd

* ''I don't know of any language which describes its expression evaluation semantics as "the constant [what constant?] is stored temporarily in a variable and the type of that variable is given".''

* Language-user manuals usually don't explicitly describe internal data structures used for implementation. That would be off-topic. Thus, your observation here doesn't tell us much. AbsenceOfEvidenceIsNotEvidenceOfAbsence. Similarly, they usually don't tell us they use stacks to implement expression evaluation and recursion. But that doesn't mean stacks are not in there. -t

* ''The usual term in language user-manuals, for what I suspect is either "the constant" or something "stored temporarily in a variable" (if I properly interpret its author's lack of clarity) is a "value".''

* My language uses a "symbol table" for all references in the VM. All variables (local or not), all constants, all temp variables (internal), classes, collections etc including procedures and functions have an entry in this symbol table. Evaluating an expression returns a handle into this symbol table which is the equivalent of a pointer to a temp variable. This symbol table contains attributes like name, type, size, etc. Your personal experience doesn't dictate what is correct. Anywhere an expression can be used, a function, variable or constant can also be used. All 3 of these entities result in a single entry in my symbol table which also means it has a type. Is that "clear" enough for you? -- DavidClarkd

** ''Your "single entry in my symbol table" sounds like a value, but why does it need an entry in your symbol table?  There are various ways to handle temporary values during expression evaluation, but I would have thought using a symbol table would be particularly inefficient.  Stack-based approaches, for example, don't incur the overhead of symbol table lookups.  Symbol tables are generally used where objects can only be retrieved by name.''

** Have you made a byte code interpreter yourself? Your inefficient comment is based on what exactly? I do all symbol table lookups at compile time not execution time (normally). I am sure that there are many techniques for looking after the result of an expression evaluation but I chose the one I describe above for many reasons and I obviously don't think it is inefficient. My simplest commands execute at about 1/4 the speed of C. I would be quite surprised to see another byte code interpreter run faster. -- DavidClarkd

** ''I have written bytecode interpreters.  I interpreted your comment that "all variables ..., all constants, all temp variables (internal), classes, collections etc ... have an entry in [the] symbol table" as meaning intermediate values are stored/retrieved in the symbol table at runtime. So, in your language, given a statement to execute like "write(b + 2 * c)" (work with me here if your language doesn't have a 'write' function or method) what would be stored/retrieved in the symbol table at compile-time, and what would be stored/retrieved in the symbol table at run-time?''

[In my language, a variable can always be put where ever an expression can but not necessarily the other way around. -top has the correct idea but doesn't use exactly the correct words.]

[Variable names don't point to values! All memory is numbered from 0-n in our computers. The only way a value can be pointed to, is with a pointer that is number between 0-n. A name can be associated with a pointer to a value but not directly. Have you seen any memory named "variable"?]

* {This is incorrect. Computers use sequences of bits to access memory. Sometimes, we use a number to specify which sequence. Sometimes, we use a name to specify it. When writing programs just about anything except assembly, we use the name. This is especially true since we don't care exactly which sequence of bits we are referring to as long as that names always picks out the correct sequence.}

* "Sequences of bits"? Are you nuts? Your computer doesn't work with bytes? Your computer doesn't complain if variables aren't accessed on byte boundaries that are an even multiple of the size of the variable? You are just playing with words. Of course you use a name to identify a memory location but it must be associated with a pointer to work. Why don't you go and study what is actually going on in the computer, before saying that others (who know exactly how it works) are wrong.  -- DavidClarkd

* {A byte is a sequence of bits. Typically with a length of 8. My computer doesn't understand variables at all, it just sees these bits in the sequence are set while these bits are cleared, therefore it clears/sets these bits over here. That's just about all it understands. (Well, there's some additional complexity involving caches and stuff, but for our purposes that neither here nor there.) Some of the variables I use get placed in registers, by what you've just said, in order to use it, I would have to get a pointer to a register. How is that supposed to work? (BTW, I do know how computers actually work, I was formally trained as a computer engineer, i.e. as someone who designs computers.)}

[Data gets into a register directly by using a memory address (pointer), a pointer or offset from a pointer (maybe stored in a register). A CPU can only work on data in a register and (in the end) a pointer is used or computed to get that data. Some CPUs have instructions that seem to work on memory directly but that is actually implemented by moving things to an internal buffer which acts like a register, again using pointers. My comment about pointers stands regardless of what your academic credentials are. Thanks for mentioning that bytes are made from some arbitrary sequence of bits (your computer probably has 13 bit bytes, right?). I obviously didn't know that! -- DavidClarkd ]

* ''Again, this appears to be conflation of a computational model with its implementation.  Bits, bytes, byte boundaries, etc., are irrelevant in terms of a computational model.  They become relevant when you implement the model.  In the computational model of imperative programming languages, a variable is a time-varying reference to a value.''

* [You must be a professor or Mathematician. Obviously all the things you just said (bits, bytes etc) are relevant to any professional program designer or programmer. My "computational model" is whatever is useful and in the end, whatever the CPU allows. The rest is just smoke and mirrors. -- DavidClarkd ]

* ''Yup, I'm a professor '''and''' a mathematician, and I've been a programmer -- including making a living at it -- for over three decades.  Bits and bytes are relevant to those who code "on the metal", but irrelevant otherwise.  You don't need to know about bits and bytes to code an inventory system in VB against a SQL DBMS.  You do need to know about values, variables and types.''

* I couldn't have used words better than your own above that show how unqualified and irrelevant your comments are. Let me clue you in, this wiki is about "software" not Math, but don't tell anyone? Obviously somebody like yourself who doesn't actually code "on the metal" is exactly the kind of person to inform others of how to do exactly that. Unlike you, I have been a professional designer/programmer for over 35 years and that doesn't include my University Degree in Computer Science/Math. I have created systems (for money) for over 65 different companies, so I obviously wouldn't have a clue about variables/values. -- DavidClarkd

* ''Actually, I do code "on the metal", and when I do I deal with bits and bytes.  When I don't code "on the metal", I don't deal with bites and bytes.  The rest of your argument is a curiously irrelevant mix of AdHominem attack and ArgumentFromAuthority, which makes it rather weak.  Perhaps you could edit it to address my point and perhaps restore your credibility?''

You are correct that I believe that my understanding of variable, value, and type are more correct than you because of my expertise. The following is a quote about this "logical fallacy".

''However, the informal fallacy occurs only when the authority cited either (a) is not an authority, or (b) is not an authority on the subject on which he is being cited. If someone either isn't an authority at all, or isn't an authority on the subject about which they’re speaking, then that undermines the value of their testimony.''

I obviously believe myself to be an authority on this topic. I know that the idea of tying the type to the value rather than the variable and the idea that values can't change comes from Math and Functional Programming. I don't think this qualifies them as relevant to a discussion of dynamic programming languages which my language in development is an example. Haskell is a statically typed language as you are well aware.

You also say my comment was an ad-hominem attack. My attack was against Math views trying to substitute for CS, which I reject. My attack wasn't against you personally but rather the fact that you describe yourself as a professor and a Mathematician.

Your view of values is equally irrelevant (as is the FP point of view) "to code an inventory system in VB". I wouldn't say your arguments are weak but more misleading and in the wrong discipline. I am sure they would be perfectly legitimate in a Math conversation rather than here. -- DavidClarkd

''If you wish to rationally discuss programming language implementation, I'd be delighted to participate.  If you're going to rail -- bitterly and pointlessly -- against math and academia, I'll ignore it.''

[This whole idea of variables and values is just nonsense (it reminds me of numbers and numerals from grade 5). All professional programmers should know exactly how it works and whoever is playing word games with -top should stop it or at the very least, sign your comments so we can justly throw our scorn on the correct person. The idea that the number 45 can never be anything other than 45 and therefore is immutable is just more nonsense. A variable (named or otherwise) can't refer to a value without it being assigned a location in memory (stack, heap or otherwise). Values have meaning only when assigned a location in memory and a proper sequence of bytes assigned. Any of these memory locations can be changed to whatever values are acceptable for the "type" of value being assigned. We have used immutable variables without names since programming began and we called them constants (immutable variable is an oxymoron). We have also written "pure" functions in all programming languages but they were just one kind of function in our toolkit rather than the only "sanitary" kind. Functional programming and this variable/value nonsense are just a form of the emperor with no clothes on. I would expect better from a grown up group of professional programmers.]

* {What did you find nonsensical about numbers and numerals? What's nonsensical about the number 45 being the number 45? Why would a value have meaning only when assigned a location in memory? What makes you think changing which value is in a memory location actually changes the value?}

* [More BS.]

* ''That's an unusually ineffective counterargument.''

* [Your set of 'questions' were so stupid, they deserved no response. This is the real world, not kindergarten! If you didn't get the point I made, there is no hope for you.]

* ''That's equally ineffective, and an AdHominem attack.''

* {DavidClarkd, It appears you won't answer my questions. So be it. But in order to understand your point, it appears I have to understand what's nonsensical about numbers and numerals. You did, after all, use that as a explanation of what's wrong with values and variables. I don't see anything nonsensical about the former, so failing to explain why you think they're nonsensical leaves me completely in the dark as to what your point actually was. There are similar concerns about my other questions.]

[When programmers talk about values, they are actually talking about the number or data stored in some memory location and normally labeled. Anything that a program talks about must have a presence in memory (at least at compile time) or it has nothing to do with the code. It isn't helpful to say that some specific sequence of bits can only be that exact sequence of bits. That is obvious. What does matter is that a single location can contain only a single set of bits at any moment in time. Almost always, that variable will contain the only value that is important, at least, until the program decides to change it. The definition of a variable is something that can change so what should we call something that can't change, an immutable variable or a constant? I am not talking about Math, I am referring to software on real computers. I have programmed many hundred's of thousands of lines of code and I can't remember a single instance of needing the previous 10 bit sequences stored at a memory location. If I did, I could easily create a stack.

Take the argument about variables and expressions. Variables are considered to be simple expressions where ever the language allows expressions. He didn't say they were the same. A language never allows assignment to an expression so in that situation they are not equivalent which he also never said.

I repeat that this whole argument is a worthless word game where all professional programmers already know what actually is. -- DavidClarkd ]

* ''So DavidClarkd, you'd expect better than FunctionalProgramming from a "grown up group of professional programmers"?  Is that what you meant?  Your confusion about values and variables, and apparent conflation of the abstract computational model (numbers, values, variables, constants and types) with concrete implementation details (memory, stack, heap, bytes, bits) is precisely the sort of lack of clarity and rigour that needs to be addressed.''

* [ I believe that functional programming is a conspiracy of Mathematicians to convince the gullible that the dual nature of programming (data and programs) is wrong and that they should try "one hand clapping". When I was at University, I loved APL, but it is like a fancy DSL that has very limited usefulness. Functional programming is also like APL in this regard. Of course '''I am confused, oh wise one'''! I don't have over 35 years programming computers in dozens of languages and produced a language/database system that sold over 30,000 copies. I obviously don't have a clue! If you want "clarity and rigour", go play with your Math. If you want useful programs that make a difference in the real world then study exactly what tools the CPU gives a language designer and stop talking nonsense.  -- DavidClarkd ]

* ''A "conspiracy of Mathematicians..."???  I...  see...  O_o''

* GroupThink is not necessarily a conspiracy, just a bad side of human nature.

* {DavidClarkd specifically said conspiracy.}

* Okay, but GroupThink can have impacts that are similar to conspiracies such that the affects of bias can still be felt. There is a lot of FP hype of late that smells much like the "pure OO" fad spike.

* ''"FP hype" is OffTopic for this page.  I think it would be no bad thing to delete DavidClarkd's OffTopic contributions, as they add nothing.''

* Would you like ME to delete all your stuff I don't think adds anything? GoldenRule, dude. Deletion without permission is evil.

* ''If you feel such a refactoring would genuinely improve Wiki, please do.  I'll AssumeGoodFaith.  That's the WikiWay.  If I wish to retain my content, I'll retrieve it from the PageHistory and put it elsewhere.''


[The other person is saying many things that are just obviously wrong and I think anyone reading this post should know it.  --- DavidClarkd ]

''By now, I suspect it's pretty clear to the reader who is "obviously wrong".''


(A sub-discussion broke out above with newer contributors, separating it space-wise from the reply below. -t)

What do you mean a it's not accurate to say variables can serve as expression? '''Variables satisfy all the properties of an expression'''. --top

''No, they don't.  A variable is not an expression.  You can assign values to a variable, but you can't assign values to an expression.  However, a valid expression can consist entirely of a '''reference to''' a variable -- which, in algebra and most programming languages, consists of its name.''

* I said variables satisfy all the properties of an expression, NOT that expressions satisfy all the properties of variables. You successfully debunked the second, but I didn't claim the second. I don't see how the second part is relevant here.

* ''Variables don't satisfy any of the properties of an expression.  A '''references to''' a variable satisfies all the properties of an expression, because a reference to a variable '''is''' an expression.  Semantically, a reference to a variable in (or as) an expression always denotes its value.''

* You are inventing unnecessary middle-man notions out of the blue. Most normal programers would agree with "variables satisfy all the properties of an expression". Any interface/communication-technique we normally use is ALREADY a "reference to" out of necessity such that we don't explicitly state such. There is no syntactical version of "reference to" that can be objectively verified to exist that is ''required'' for expressions. Plus, it's '''redundant''': a variable is already a reference to content such that a "reference to a variable" is a "reference to a reference to content". One can pretend there is such a layer, but it's not necessary nor objectively verified to exist.

* ''That "most normal programers [sic]" would allegedly make statements grossly lacking in accuracy and precision is no reason to join them in being wrong.  You do understand that what a variable '''is''' and how a variable '''is used''' are two different things, yes?  As for syntactical verification, note that statements like "var p", "p = 2", and "x = p + 2" are semantically different, despite using the same name -- 'p' -- in each example.  The first is purely a declaration, and the latter two both make reference to 'p' but in significantly different ways: the former assigning a value to 'p' and the latter retrieving a value from 'p'.  In only the last does the reference to 'p' "satisfy the properties of an expression" in the sense you obviously meant.''

* Again, any extra properties/abilities that variables have beyond expressions is irrelevant, as explained above. The issue is a minimum set of properties/abilities, not the maximum nor additions. Thus, variables being able to hang out on the left side of an equal sign and do assign-y things doesn't disqualify the original statement. '''It did NOT claim them equivalent'''. Your test disproves none of the statements. As far as your implied proper model of what variables really are or how they work, that's right back to the usual "canonical semantics" battle of the parent topics such that I won't repeat all that here. (Note that "programer" appears to be a valid alternative spelling.)

* ''"Variables being able to hang out on the left side of an equal sign and do assign-y things doesn't disqualify the original statement."  Actually, that's precisely what '''does''' disqualify the original statement.  Regardless, semantically, a variable appearing in an expression -- whether in programming languages or elementary algebra -- always denotes a value.  An expression like "a + 3" isn't actually adding the variable 'a' to 3 -- that's mathematically meaningless -- it's adding the value denoted by the variable 'a' to 3, which makes mathematical sense.  We add numbers to numbers; we don't add variables to numbers.''

* You are not clear on the logic of disqualification (re: "that's precisely what does disqualify the original statement"). Please elaborate. And the second part is an implementation decision, not an observable fact. The implementation may use values, zimbos, groggnuts, or fliptards: it can use what it wants as long as the output is as expected. And if your reply is going to mirror parent topics, please reference instead of repeat.

* ''What is a "logic of disqualification"? What part is an "implementation decision, not an observable fact" -- the fact that variables denote values when referenced in expressions?  Or the fact that we add values to values, we don't actually add values to variables because variables denote values?  Neither of these are an "implementation decision".  Both are mathematically true, by the definitions of the relevant terms.'' 

* It may be a valid or workable model, but you have not proved it a ''necessary'' model. (I reworked my prior "disqualification" question.)

* ''If you can find a way to add variable 'a' to 3 without knowing the value of 'a' and have the result be more specific than 'a + 3', you're a better mathematician than me.  Or anyone.  Or anything.''

* Huh? I don't see the relevance. Math does not rigorously define implementation of "value" or "add". And it may be a false assumption that computer languages intend to implement "pure" math. They implement a UsefulLie and/or subset version of math as a tool such that the tool users have found it acceptable for their intended usage. You seem to be caught up in some kind of idealism here. It's a tool, not a god.

* ''Ok, as a tool, how do you sum a variable with 3?''

* One asks the interpreter to do it, and they don't have to worry their pretty little head about the implementation details. Nice, huh?

* ''That's a dismissive non-answer.  The correct answer is that you can't sum a variable with 3.  You can, however, sum what the variable contains -- its value -- with 3, because both can be numeric values and we know how to sum numeric values.  No one knows how to sum a variable with 3, except by retrieving a numeric value from the variable first.''

* That's your pet interpretation. Semantics are in the head and can be different whether you like that fact or not. '''Repeating your pet model of "value" over and over again as if it's a universal truth will NOT change my mind. You must PROVE it canonical first''', not merely claim it like every other aggressive ego-pumped web insister out there.

* ''No, semantics are not "in the head".  Semantics are in the language definition.  Human interpretation of programming language semantics may be "in the head", but that's irrelevant.  As for it being my "pet interpretation", if you can show that 'a + 3' is something other than 'a + 3' -- in algebra, or any programming language you like -- until you know the value of 'a', I'd be interested to see it. I.e., logically, you can't add a variable to a value without taking into account the variable's value. ''

* If by "language definition" you mean the language manual, my model '''does not contradict''' such things, as repeatedly explained. Re: "logically, you can't add a variable to a value without taking into account the variable's value" -- That's ''also'' true of my model. How about that! 

As far as the second paragraph, it covers material we've been over already, and I've disagreed with that, at least as the standard canon. It's merely one possible viewpoint/model among multiple.

''I'm not aware of any alternative viewpoint to the above that has any significant traction.''

Your techniques for objectively measuring "traction" appear to be flawed and based on personal interpretations of cherry-picked English phrases.

''That's an AdHominem attack, not a counter-argument.''

No, I said your technique is flawed there, not that you as a person are flawed. (You ''are'' flawed, but that's another topic.)

''That too is an AdHominem attack.''

Okay, ''that'' time I was guilty.
------------

I'm a flexible guy; any model that has a correct IoProfile (produce correct output) is considered "correct" (physical time & resources aside). '''Let them ALL be free to CO-EXIST!''' --top

http://api.ning.com/files/iTBb*6jdgFZQlIfA-QNe0R6m7QhffIPJrgHf6ESvx3mM6Pu-w9l*qnNpEpkrzJWQAerTmZNYnD8FpgvkvvJ7h5xxkde8ofr8/RainbowDove1.jpg

Suggesting that the emperor has no clothes also seems harmless unless people all remove their clothes and freeze to death. Sometimes the truth actually matters. If 1 system contains A and B and another only has B, can we tell which is better? Which will provide more tools to solve the problems? Can a system that tries to imagine away data, be equivalent to systems that deal with both data and programs? -- DavidClarkd

I don't understand what you are trying to get at. Perhaps a specific textual example would help. If a tool is flawed in an objective and practical way, then we need an objective scoring system to identify such a flaw. -t

I am sorry I can't explain simple sets easier than I have above. Functional programming, which is the basis for this variable/value malarkey, wants to juggle data on the stack between functions and avoid state (changing variables) at all costs. I say that programming is about data and programs and any language that tries to take either away, is flawed. I can easily (and do) create "pure" functions in C and I avoid all global data like the plague. Object oriented programming that has objects that encapsulate state and programs is antithetical to functional programming as changing the object variables is considered a "side effect". It is "impure" and "unsanitary"! There are no concrete examples as this is a conceptual argument. You either understand it or you don't. Even if you understand what I am saying you don't have to agree with me.  -- DavidClarkd

''Your misunderstanding of FunctionalProgramming is profound.''

So who are you oh "nameless one"? I have made many comments elsewhere on this wiki about Functional Programming and unlike you, my name is attached to every one of those opinions. FP proponents are always pontificating about how great FP is and it has been around for at least 15 years, so where are all the great FP programs? I am not the one makinig outrageous claims above how great FP is so the onus is on you to "prove your case". Make a new document and I will debate any and all of your points. By the way, I don't think that all the features and ideas in FP are bad, but FP didn't invent most of those features either. -- DavidClarkd

''My name is DaveVoorhis, and your misunderstanding of FunctionalProgramming is profound.  You might wish to ask these guys about "great FP programs": http://cufp.org/''

--------------
'''Types and Arrays Example 1'''
 <!-- Variation A -->
 <variable name="foo">
	<array type="float">
		<value representation="123.4"/>
		<value representation="76"/>
		<value representation="66.77777"/>
		<value representation="430000"/>
		<etc...>
	</array>
 </variable>
 
 <!-- Variation B -->
 <variable name="foo">
	<array>
		<value type="float" representation="123.4"/>
		<value type="float" representation="76"/>
		<value type="float" representation="66.77777"/>
		<value type="float" representation="430000"/>
		<etc...>
	</array>
 </variable>
----
Footnotes

[1] Some language docs do "leak" implementation details. Some may argue this obligates implementers of competitor interpreters of given languages to "stick to" the documentation in terms of implementation, but I generally consider hints about the implementation to be "courtesy info" and not the establishment of rigid implementation restrictions. Programmers sometimes want implementation details to help them tune performance. But a competitor interpreter that has a different performance profile is still usually considered the "same language" regardless as long as the IoProfile is the same. To treat such documents and implementation hints as rigid canons is silly and impractical. Using IoProfile as the primary comparison standard better reflects practical concerns of shops and programmers than "the manual". -t

''I don't know if it fits your IoProfile notion or not, but it is for precisely this purpose that validation suites exist.  See http://www.plumhall.com/ZVS031_mp.pdf for example.''

Somebody helped make empirical testing easier. Good.
------

"TTM" is a working & local acronym shortcut for TopsTagModelTwo.

''In database research circles, TTM always refers to DateAndDarwen's TheThirdManifesto.  To avoid confusion, I suggest at least choosing a different acronym.  TopsTagModel would be ideal as both shorthand and WikiPage.''

Oh for pete's sake. Not this again. TopsTagModel has the wrong content. TTM2

''Why not simply move the existing content on TopsTagModel to (say) TopsTagModelDiscussion, thus freeing up TopsTagModel to be the definitive source of information about TopsTagModel?  You could even use TopsTagModel to refer to it instead of TTM2.''

There are back-links that would need some adjusting. I'll consider it, but not today.

''What backlinks?  It's a trivial change -- for now, you could simply copy everything in TopsTagModel to TopsTagModelDiscussion and just leave a link to TopsTagModelTwo.  If you like, I'll do it for you.''

Existing reference to TopsTagModel would need to examined to make sure the context or relevancy isn't changed, or adjusted without violating authorship integrity. You know, Link Management 101.

''How would the context or relevancy have changed?  They refer to TopsTagModel, so why would improving the content -- so that it actually describes TopsTagModel -- be a bad thing?''

YOU created that page, not me. It's NOT the reference I want in what I write. I'll adjust it myself, just not today.

* [I created that page. I did it to encourage you to put the information about your model in a single place so it could be easily found and referenced. I also included a suggested format. One that would allow me to easily find the information I needed to use and analyze your model. Currently it's scattered over multiple pages and it's no longer entirely clear which of these bits belong to your current model and which don't.]

''No, I didn't create that page, but it seems an appropriate PageName.  What reference would you prefer?''

If I clean up that page, then I cannot use "TTM" as an abbreviation because of your Date overloading complaint above. If we leave it where it is, than TTM2 is a sufficient abbreviation. Thus, it appears simpler to leave it where it is and I use TTM2 for an abbreviation when desired. KISS. -t

''If you clean up that page, then you don't need "TTM" or "TTM2" as an abbreviation -- you can use something better, a PageName of TopsTagModel -- and we all (you included) gain a single, definitive, point of reference for TopsTagModel.''

I often prefer to use abbreviations when talking repeatedly about a given issue. Further, too many duplicate wiki-marked-names is often distracting in that one does not see unique ones in the mix. The unique names get lost in the repetition.

''Why not clean up TopsTagModel and create an abbreviated PageName as an alias, like I did with SchizoidGibberishWikiAuthor and SgWa?  You could create TpTm as an abbreviation, say.''

I don't think it's wise to add to the wiki topic global name-space for a specific discussion. Topic-specific abbreviations are sufficient to do the job. 

''Why not?  Its effectively infinite, and the need for new abbreviations is rare.  Whilst topic-specific abbreviations are sufficient (though, in this case, it still leaves us without a definitive page for your tag model), you seem oddly insistent in using one that seems likely to cause confusion.  That's especially true as the authors of TheThirdManifesto (aka TTM) have made an explicit effort to clearly distinguish values, variables, and types.''

I choose not to do so for the reasons already given, per authoring decision of name-space and textual presentation trade-offs. I don't wish to debate it any further. It's a difference in style preference. If you can demonstrate some kind of reliable general WikiZen preference via surveys etc., I'll reconsider.

----
CategoryMetaDiscussion
----
JanuaryFourteen