'''Please see''' TopsTagModelTwo. This page is slated to be moved to another topic, per discussion in ValueExistenceProofFour.

''I don't see anything worth keeping here. I'd suggest you just delete this when you put the canonical description of your model here.''

The Star Trek example illustrates differences in viewpoints about how science is done and helps explain some of the philosophy behind model design decisions.

{It doesn't explain your model, though, despite the promise of the PageName.  It would be very helpful if you put your model here.  Ancillary content can go on pages like TopsTagModelRationale.}

After the "value" fights settle, I'll consider topic partitioning adjustments.

''The Star Trek analogy can be recreated if needed. I'm much more concerned about getting your model documented.''

TopsTagModelTwo is the most-thorough description so far. If you have questions about fuzzy areas, feel free to ask there.
 
---------------
Purpose: <Please describe what your model is supposed to accomplish (as opposed to what you wish to accomplish with your model.) Please leave examples and exposition for the "Informal Explanation" section.>

Parts: <Please describe the parts that make up your model. Again, save examples for later.>

Rules: <Please describe the rules that govern how the above parts are put together, how they interact, and how they lead to the conclusions the model is supposed to provide. Again, save examples for later.>

Informal Explanation: <Put examples with explanations here. Keep in mind, the parts of your examples that pertain to the model should not use anything not already mentioned above.>

See TopsTagModelTwo.

-----

I thought I've done this already. How about you put YOUR dynamic type model in your Grand Ideal Format to serve as a reference, which I can then use to put mine in the same Grand Ideal Format. Logical. -t

''Where?''

All over our ThreadMess.

''So why don't you put it here so it can be found?''

It confused you even after I repeated some of it four times such that I have a low expectation that moving it here will significantly help. It's likely useless busiwork. It appears the be format and delivery method that's off, not the physical location of it. Thus, I'd like a reference sample.

''Our confusion stems from the things you won't tell us about your model. You won't tell us how to design an experiment. You won't tell us what the syntax and semantics of your semi-abstract machine language is even though we need it to convert the source code in order to perform your experiments. You won't tell us how to tell if an experiment indicates a "tag" or not. None of that would be helped by a reference sample. But that's really a moot point since you were given one. http://lucacardelli.name/Papers/TypeSystems.pdf ''

Even if that stuff was true, how would moving it here solve that?

{There is no single, definitive presentation of your "tag model".  It's spread over multiple pages, which makes it difficult to understand.}

* Again, I've repeated some of it multiple times and it never clicked with you. Why would re-position change that? I didn't get an answer for that.

* ''There's no guarantee that it would, particularly if you don't bother to address the concerns we've already raised. But if you do address those concerns and use the format above, there's some chance of it. There's no chance as things stand now.''

* I strongly sense that the real problems are philosophically much deeper than text positioning. I'm not going to waste tens of hours on a long-shot.

* ''But you'll spend much more time than that on a no-shot. To each his own.''

* No-shot A versus no-shot B. Hmmmmm.

And the Luca paper sucks eggs as a common reference, and is too long. It seems you lack real-world documentation experience, instead hanging around professional students all your life. Burn that mother!

{Rather than complain about the Cardelli paper, wouldn't this be an excellent opportunity to demonstrate how a "common reference" of the right length, written by people with real-world documentation experience, should be done?  (By the way, is your rudeness and unprofessional language really necessary?)}

You are being rude by saying repeatedly "I won't tell...", which is flat wrong. You don't think like typical programmers and so are not a good test case for the existing description. You have too much baggage in your head that you cannot untie to evaluate something different. It's like somebody who has been cloning Rembrandts all their life to evaluate Monet.

I told you my goals, and the Cardelli paper does not address those goals.

* {That's fine.  Wouldn't this be an excellent opportunity to create a "Top paper" that not only definitively explains TypeSystem behaviour in dynamic languages, it demonstrates how a "common reference" of the right length -- written by people with real-world documentation experience -- should be done?}

* A language-specific manual is a different thing than a general model.

* {Huh?  You must have missed what I wrote before.  Wouldn't this be an excellent opportunity to create a "Top paper" that not only definitively explains TypeSystem behaviour in dynamic languages, it demonstrates how a "common reference" of the right length -- written by people with real-world documentation experience -- should be done?}

* Good documentation takes time and thought, especially with something as ethereal as "types".

* {We're in no hurry.  Take your time.}

* After the SmeQl implementation ;-)

''It's wrong? Really? Ok, then where do you describe the syntax and semantics of your semi-abstract machine language? Where do you tell us how to design our experiments? Where do you tell us how to tell if the experiment indicates a tag?''

I've described them fairly well already. And it's not really a "syntax" other than the XML model of the structure of a variable. The engine to run the models against the XML often have to be custom built per language. That's life: '''every planet Kirk lands on is different'''. We can only provide reference or base models/engines based on common patterns of past planets; science has to apply them to an actual given planet. There's no shortcut for science. Sure, we can dissect the actual interpreter, but that's thousands of lines of code. And manuals are usually vague when it comes to "types" or need to be empirically verified anyhow to make sure we are interpreting them correctly.

Spock may say, "This planet looks similar to a class R or class Q planet. I'm going to run tests and models for R-ness and Q-ness to see how close they fit. If they don't fit, then we'll select or devise a new set of tests based on what we find in our first set of tests."

http://www.startrekdesktopwallpaper.com/new_wallpaper/Star_Trek_Enterprise_NX01_On_Burning_Planet_freecomputerdesktopwallpaper_pp.jpg

To Boldly Go Where No Type Has Gone Before!

''We keep asking you about them because you've never described them. (Feel free to prove me wrong by pointing out where you did.) So, now it's not a semi-abstract machine language. It's an XML model of a variable. Could you give me your current model with the XML in it's proper place? (Or if you have a previous description of such, point out where). As for your analogy, we're asking you how do we run a test for "R-ness" and "Q-ness". Spock will, before he even knows that planet exists, already know how to run those tests. For R-type planets, he would know to check if the planet is orbiting a star. For Q-type planets, he would know to check for erratic orbits around a star. So how do we run yours?''

That's a catalog of language or operator design "patterns" you speak of. The model is more of a kit for building experiments based on past experiments and patterns, and applying Sherlock-Holmes-style skills to devise experiments for the surprise elements that the standard kit cannot fully answer (emulate). Is a set of patterns more important to you than the "mechanics" of processing? In other words, is thoroughness of the details of "processing" known patterns more important to you, or the depth of the pattern catalog?

''I thought your model was a tool for predicting output. Now it's a kit for designing experiments? Anyway, what's most important to me is that I know how to use your model properly. It's really frustrating when you won't tell me that.''

They are not mutually exclusive. How does one tune a model to make predictions? By experimenting. If you know a workable alternative, I'm all ears. I'll explore different ways to present it being my past attempts didn't work.

''Just as long as it's not the way suggested at the top of this page, eh?''

I'm not sure bifurcating "parts" and "rules" is the right way. For example, if documenting an OOP API, listing the methods separate from the objects they belong to is probably a poor choice, at least as the primary grouping.

''Fine. If your model has rules that are so closely tied to a part that it doesn't make sense to separate them, put those rules with its part. Any remaining rules should go in the Rules section.''

I'm not sure I agree with that grouping strategy. It's one grouping factor to consider, but not the only.
----------------
'''Regimentation''' (Draft)

This is suggestions for ways to ensure we study at all known possibilities based on experience with existing languages. This does not ensure we cover all basis of new languages any more than Trek's planet classification kit ensures Kirk can know all experiments to study a new planet up front. But we can catalog known tests at least so we have a check-list of know tests to try. New tests would be devised for mysteries or ambiguities not found in the known set.

 for v = each different way to declare variable
   for s = each single operand operator
     display results for s(v)
   end for s
   for d = each double operand operator (such as "+")
     for v2 = each different way to declare variable
       display results for d(v, v2)
     end v2
   end d
 end for v

''If the language allows for nested structures, would structures with different nesting depths count as a "different way to declare variable"?''

I generally have been only considering scalar variables to keep the discussions focused. 

''So now your model only works on dynamic, non-stupid languages that don't allow nested structures. I don't think there are too many commonly used languages left at this point.''

What is "non-stupid"? Is that back to the canonical string BS? For the zillionth time, the model does NOT depend on CSR's!!! Stop lying. And it does work on non-scalars, it's just that it greatly expands testing combos. And as I've said before, I limit it to dynamic languages to keep the model simple so it's easier to grasp. Unlike you, I value simplicity and clarity.

''I don't know what you meant by "stupid" you never told me. I didn't mention CSRs above. Where have I lied? And, finally, if it does work on non-scalars, why did you answer my question about non-scalars by saying you weren't considering them? Why not just tell me how it would work with non-scalars?''

By consider I did not mean "never thought about". Let me clarify: I choose not to introduce them in these topics. I wish to settle simpler issues with WikiZens before diving into more complex issues. And "stupid language" was mentioned under the definition topic, not the modeling topics. Thus, it's moot here.
----
SeptemberThirteen