Value Existence Proof Four

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)?

More explicitly:

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 ValueExistenceProof<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.

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)?]

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);         // ????
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?

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.

[ 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 ]

[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"?]

[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 ]

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.]

[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 ]

[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.

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

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.

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

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