Example Two Rooms

Example "Two-Rooms" based on DefinitionOfTypeTag:

Observation Set in room "NTL"

  f1(thingA) == f1(thingB)  // test a1 result: True
  f2(thingA) == f2(thingB)  // test a2 result: True
  f3(thingA) == f3(thingB)  // test a3 result: Invalid, can't do in NTL

Observation Set in room "TL"

  f1'(thingA) == f1'(thingB)  // test b1 result: True
  f2'(thingA) == f2'(thingB)  // test b2 result: False
  f3'(thingA) == f3'(thingB)  // test b3 result: False

Here's a proposed explanation for both observations that can be emulated with stuffed animals, boxes with crayon labels on them, 2 rooms, and written step-by-step numbered procedures about looking at the contents of the boxes (that we normally call "functions") such that 1st graders can carry out and all can watch while it happens and all have a copy of the procedures. (Any "thing" with ambiguous boundaries is encircled with yellow rope with a sign in front to make sure.)

In room TL every "thing" has two compartments, that we'll call "bins" for brevity. One bin we'll call "T" and the other "V".

But in NTL every thing has only one bin: "V".

In tests a1 and b1, f1 and f1' only look at bin V, and thingA and thingB have the same content such that they are equivalent (they both have the same kind of stuffed animal, a green monkey, for example).

In test a2, f2 looks at only at bin V because NTL has no bin T. Since the contents of bin V are equivalent in both things, the result is True.

However, in test b2, f2' looks at both bin T and bin V. Bin V is equivalent just like in test a2. However, bin T is not the same. Since f2' must find a match on both bins to report True, it reports False because one bin (T) does not match.

In test b3, f3' looks at bin T. In test a3, f3 cannot look at bin T since in room NTL, things have no bin T's, so it's an invalid request.

As far as programming equivalency, we can compare these to language operations that compare equivalency of value, and/or type information. It can illustrate why tag-free languages have no "typeName()" kind of operation that returns a variable's type, such as "integer" or "date", yet still have operations like "isNumeric", or why variables assigned with quotes act different than those without quotes (a=123 vs. a="123"). Some operations look in or use both bins and some only look in or use one, perhaps because there is no second bin in some languages/rooms (or a given language never uses the second bin...in a detectable way at least such that erasing it from the model produces the same results).

Now you have suggested that "tag" is the equivalent of "type" such that I should drop "tag" and just use "type". And then you also said that parse-based parameter checking like that in Example CF002 does mean that "types are involved" or at least it's legitimate for a regular developer to say "types are involved". If they are involved, we cannot test that fact if they are equivalent to tags. In other words, there's no test to prove that CF uses a bin T for variables; and the existence of only bin V is sufficient to produce the right answer (mirror the program results). So yes we can pretend that bin T exists in the CF room's things, but it changes no known test done in room CF, and thus it does not add to explanation. Maybe you can add something else(s) to "things" to explain the test results, but you have not clearly identified what those additions are in terms that can be put into our 1st grade room experiments. And if it's always there (or allowed to be used), then it does not explain the different kind of rooms. You cannot have your cake and eat it too: always there versus lack of existence (or banning usage) affecting results.

Note that dynamic languages that are tag-based languages tend to pass and fail equivalent or very similar groups of tests compared with tag-free languages. I've yet to find one that dances in the grey area. Thus, the model has a consistency outside of one language. Thus, if a room allows things to have 2 bins, it's consistent across all the things in the room. (At least on the scalar scope). We could get the equivalent results by just saying that no tests in room NTL use the bin T of things, but the model is more striking and visual and clear if we just chop it out altogether. It's easier to visualize not doing things to something if that something simply doesn't exist (and reduce emulation mistakes since if you forget, the lack of existence is a blunt reminder. You can't put on your glasses if you don't have a head.) -t

Sorry, this "room" analogy loses me. How or where exactly is "reference to type" not equivalent to "tag" in CF?

Serious, it loses you? Eye eye eye. It appears we think so much different from each other that communication is nearly impossible. The goal was to create a "mechanical" model that ordinary people can relate to on everyday terms built with everyday items and watch the model "run" and know what is happening because it is built on everyday concepts and parts, and the model can predict and demonstrate (or emulate) what programs are doing (with issues at hand). Observers don't need to know Fluppenheimer's Spasticated Typeclass Theory to follow along. (We can tweak the above to formalize it bit more, but it would lengthen written descriptions.)

As far as equivalency, it's a conundrum. If they are equivalent, then CF "has no (detectable) types" (for scalars at least). But you said it did based on an earlier version of Example CF002 in DefinitionOfTypeTag.

• You've raised this apparent tag vs type "conundrum" in the context of CF before, but I'm afraid I don't see the conundrum. Could you explain?

{Ok, you intend it to be a model (presumably of program behavior). What you need to actually make it a model is a description of how to map program behavior to your boxes and stuffed animals. You also need to explain how this model is relevant to the issues on DefinitionOfTypeTag (I'm also presuming that it's related, although it's hard to tell.)}

I thought I did. I'll ponder alternative approaches. Maybe if I say the same thing 20 different ways, it will eventually click with somebody. 19 aint good enough.