Tops Tag Model Two Discussion

I find TopsTagModelTwo to be rather baffling. It doesn't describe the model or how to use it. The page appears to consist of internally-documented snippets of code, but there's no indication of where/why/how they are supposed to be used. It also appears to be incomplete.

TopsTagModel is where I would expect "Top's Tag Model" to be documented, but it's discussion about the model rather than presentation of it.

DefinitionOfTypeTag appears to make some attempts at definitions, but doesn't describe how the model works.

TypeTagDifferenceDiscussion seems to come closest to describing how the model works, but it's not clear whether it's intended to describe the model or merely demonstrate its application. There certainly isn't any section that introduces the model, provides an overview, or clearly describes the parts of the model and how they interact.

TypeTagDiscussion talks about the model but doesn't describe it and only refers back to DefinitionOfTypeTag.

TagFreeTypingRoadMap doesn't appear to link to anything that definitively describes the model.

Where is "Top's Tag Model" definitively and completely documented?

It's not completed yet. I will present more pseudo-code examples and then work on related descriptions and intro.

Regarding updateTypeType()

[Your] func updateTypeTag(vname: string, typeName: string) apparently changes the type of a variable independently of its value representation. Why?

That's just a low-level accessor. In practice, it probably would not be used in isolation, although the details of that depend on the specific language being modeled. In other words, both the type tag and the value are usually changed together in the same mid-level operation/function. An example of where the type tag may be changed in isolation is a "cast" (conversion) operation that converts a number to a string. However, that's not necessarily the only way to implement such.

How do we know what are "low-level accessors" (presumably inaccessible outside the API) vs high-level functions exposed by the API?

That depends on each specific language being modeled. Examples for common/typical languages would be given, but the details about how the parts are put together is up to the kit user. If a kit user wants to add extra GateKeeper levels, etc., that's up to them.

Why would it depend on the specific language being modelled? What language consistently meaningfully changes the type of a value but not its value representation? For example, how could you cast an integer 23981029 to a float 23981029.0 without changing its value representation?

That depends how it's actually stored and/or modeled. It may also depend on the kind of conversion combo being that some conversion paths can simply change the tag and others require adjusting the value (representation). A lot of that detail is language-specific. Also note that some "inspect-able" artifacts may be added by operations such as Write statements. We often don't really know what Write statements are doing with values and there may be multiple ways to model given observable behavior.

Can you given an example of where it is possible to cast the integer 23981029 to a float 23981029.0 by only changing "the tag" but not the "value (representation)"?

What language? How do you know that the ".0" (decimal position) is actually stored in RAM rather than an artifact of the Write statement (and similar operations)? If it's an artifact of the Write statement, we don't have to change the internal representation. Note that both "viewpoints" may produce the same results in a given language such that the modeling choice is a matter of personal preference or parsimony.

Any language you like, but assume a numeric literal with a ".0" suffix is a float, and without any decimal point it's an integer.

An expression such as "x=123.0" doesn't necessarily have to store the ".0" internally. It could simply store the string "123" (or some compressed form) and set the tag to "float". (Write statements perhaps "add it back", as a convention for all floats. As a side note, many scripting languages don't make an explicit distinction between an "integer" and a "float" or "double", but rather roll them up into "number".)

True, but in-place mutation of a value is an optimisation rather than standard practice -- it certainly has no conceptual basis -- and it (generally) can't be done if you're (say) casting from an int to a string and the value representation is binary.

I thought it was clear above that it may not work for all conversions. As far as "conceptual basis" and "standard practice", unless you can measure and document such in an objective way, a personal viewpoint won't do us much good. It appears to be an implementation detail and there are multiple ways to do the same thing; I doubt there is a canonical implementation.

Where does your API provide information to the API client in order to make an appropriate decision about whether or not it can perform an in-situ typecast via updateTypeTag()?

Like I've said many times, those details depend on the specific target programming language's behavior (IoProfile) that one has to glean from the language documentation and/or code experiments. Ideally sample model implementations mirroring each common dynamic programming languages would be provided, but those are not currently available.

What does "IoProfile" have to do with whether or not a typecast alters a "type tag" or not? It's internal.

Yes, it's internal, that's my point. It's an implementation detail, such as whether to use two big gears or three smaller gears in an orrery. As long as the planets match the actual positions in the sky ("sky profile"), it does the job either way. In some situations, one can implement a typecast in the model simply by changing the type tag alone.

How would the IoProfile of language that implements typecasts via in-situ changes to type references differ from a language that implements typecasts by returning a new value of a different type? It looks like you're exposing internal mechanisms -- i.e., updateTypeTag() -- that don't benefit from being exposed and needlessly complicate your system.

It may not be different. The externally-observable behavior (such as programming output) could be identical between both design choices. Often there are more than one way to do the same thing. And I am not sure what you mean by "exposing internal mechanism". The API is for building internal infrastructure. It's supposed to be "internal". You are quibbling about personal design decisions. Write your own version of this tag model if you don't like it.

I did write my own version (though not of the "tag model" per se) at TypeSystemCategoriesInImperativeLanguages. As your API does not distinguish the public API from private methods, we have to assume it's all public.

There are no public API's.

Then how do you expect anything to make use of your API? If there are no public APIs, then nothing is accessible, and therefore your API is not usable.

I meant to app programmers. The API's given are for model interpreter builders (or at least interpreter core). That should be obvious.

What is the public API that is available to a "model interpreter" builder?

I'm not understanding the question. All the API's shown are available to the builder. They don't have to use them all if one or more don't apply to a given language or implementation decision. Some may only be used by other API's, per language and/or design choice, but the levels are not hard-enforced; for one of the stated goals is to make all the guts transparent to the simulator builder. This practice may differ from a production system in which one typically wants abstraction levels/layers more tightly controlled to prevent boo-boo's or encourage a division of labor. Further, different languages may be best done using different layering arrangements such that hard-layering up-front is PrematureAbstraction.

In short, why is updateTypeTag() available to the "model interpreter" builder, given that a "model interpreter" (which I take to be one that doesn't require high-performance optimisations, like implementing typecasting via in-situ changing of a type reference without changing a corresponding value representation) wouldn't need such a thing, given that its use would never be visible in an IoProfile?

The parts don't have to be "visible" to outsiders (IoProfile) and there's no rule that says they should, anymore than the gears in an orrery need to be visible to viewers. A tool to compare accuracy or "results" equivalence of different orrery's, similar to an IoProfile, typically wouldn't compare on gears. It would look only at the planet positions, not the "guts". (Ideally, gears shouldn't be visible at all, but a model tinkerer or hobbyist may want to see them.) And yes, there are different ways to do the same thing; that's not news. The current design uses it. If you want to present a different design variation, please do rather than keep complaining about this one. It's getting old. Fork away...

A different design is presented at TypeSystemCategoriesInImperativeLanguages.

I meant if you want a variation on this one. I changed the text to clarify that.

If you corrected the flaws in TopsTagModelTwo, it would be the same as TypeSystemCategoriesInImperativeLanguages.

There are no objective flaws. You just mistake your pet head models for universal truths due to an annoying personality flaw. Now, bug off!

Your model may be functional -- it's hard to tell -- but it certainly lacks parsimony. That has nothing to do with either "pet head models" (?) or their conflation with "universal truths", which is a notion found only in mathematics. I don't claim TypeSystemCategoriesInImperativeLanguages represents universal truth, only that it better achieves some of the same purposes as TopsTagModelTwo by better reflecting popular imperative language documentation and implementation, and by using conventional terminology in a conventional way.

You've claimed that already, and I disagreed. LetTheReaderDecide. And it inadequately deals with "soft" or "parse-based" polymorphism (SignaturesAndSoftPolymorphism) in my judgement, or at least we choose to target a different scope: "popular" dynamic languages versus those likely to be encountered in the field. I chose the second because potentially obscure scriptish languages are often found with or embedded in niche products that one is asked handle at work, in my direct experience. Thus, I chose to make it easy to handle a wider range of polymorphism techniques. There is nothing wrong with targeting our models to somewhat different audiences.

In what way does TopsTagModelTwo handle "soft polymorphism" that TypeSystemCategoriesInImperativeLanguages does not? (Before you answer, note that this has been discussed already in SignaturesAndSoftPolymorphism.)

I gave a code example at "Plus-Sample-1". Essentially such IF statements (or equivalent) can be anything TuringComplete the kit user needs to model a given operation(s), not limiting it to hard-coded polymorphism or anything odd or goofy. It's pretty simple and strait-forward in my opinion. If it's already been addressed, then please indicate via a title or PageAnchor where you addressed it.

See the thread on SignaturesAndSoftPolymorphism starting with, "It's a niche that doesn't have to be covered."

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