Continuation from TypesAreSideFlags (to be renamed TypesAndSideFlags eventually.) Issues raised include: * Use of "flag" versus "tag" term * Is it a model, merely an analogy, or both? * Is it "useful"? * Do possible flaws or limitations make it non-useful? * What are the practical alternatives? (Please put comments about the list below in the discussion. It's meant to serve as a table of contents, not a discussion in itself.) ------- Originally extracted from SantaEverywhereFallacy (how'd it get that far off topic?): ''Any'' definition of "types" is useless to most practitioners, including the "TypesAreSideFlags" definition you propose. The only practitioners that even matter are those to whom a definition of types would matter - a population that, I suspect, is closely correlated with those who develop languages and wish to discuss or research types and type systems in order to make intelligent decisions. So, no, I don't care about the 'problem', and I don't even see how it is a 'problem' or why you "have to" care about it. ''This is incorrect. Practitioners care when it affects how the program works. Flag-based dynamic languages act different than flag-free dynamic languages. For example, ColdFusion and PHP act very different in this regard. How are you going to explain those differences without reference to the flag model?'' [Trivially. Reference is made to specific behaviour without the need for, or any benefit from, a (questionable) pseudo-model.] This is a very curious response. Many people work better if they have a mental model for why things do what they do (even if it's a UsefulLie). That is often better factoring than describing each and every case as if they are all independent little cases. It becomes like English spelling instead of a purely phonetic language. It's a less compact form of information: a big bag of arbitrary cases. The total errors caused by forgetting the myriad micro-rules may be larger than the total errors caused by the larger-scale model being imperfect. --top [I am referring to your ill-defined "TypesAreSideFlags" pseudo-model in this particular case, not models in general.] Same thing. If the side-flag model enables a developer to understand, or at least predict, language behavior better or equal to memorizing behaviors as mostly independent special little cases, then why is it a problem? Some people have an almost photographic memory for tons of small menutia, but some don't and prefer simpler rules if they exist. --top ''Seems like a big "if". I imagine you could demonstrate that this side-flag pseudo-model of type-implementations could be applied to a few languages (at which point it makes which predictions, exactly?) - and perhaps those are the languages you care about - but I currently have no reason to believe this model won't fall apart when dealing with MetaObjectProtocol''''''s, TypefulProgramming, TypeInference, type-driven coercion and static dispatch, sub-structural typing (uniqueness types, region inference), dependent types, etc.'' [As stated elsewhere on this page, the "side-flag model" isn't a model. It's at best a statement that some language implementations associate type tags with run-time values, and at worst merely a terminological equivalence of "type" and "side flag".] I actually don't know how the mentioned languages implement types under the hood. They merely act like they have type flags or like they lack them. [ There is no substance, mechanism, algorithm, or other content within the specified "model" that allows us to make predictions about behaviour.] There are examples under TypelessVsDynamic, particularly near the bottom under heading title "Testing For Flags". [To be (closer to) complete, it needs to provide (at least) a series of steps (or some equivalent structure) that allows us to consistently and unambiguously determine an output (some specification of behaviour) for a given set of inputs (a snippet of code, presumably). In the discussion above, it's apparent that the steps exist in your head -- as you've clearly, for example, used them to distinguish ColdFusion behaviour from PHP behaviour -- but they haven't appeared on this page because I can't use "type = side flag" (which is essentially all we've got from you) to distinguish ColdFusion behaviour from PHP behaviour without assuming (i.e., ''guessing'') what you mean by "type = side flag".] Again, see TypelessVsDynamic for examples. ''Try applying your tests to Haskell and ML.'' Someday maybe. Note that I never claimed the model is universal. If it doesn't apply to some languages or parts of languages, that does not by itself make it useless or worse than the alternative. It's a matter of optimizing MentalIndexability of how we remember language behavior. In practice people tend to use a combination of big-picture models in conjunction with exceptions to the big-picture models (DeltaIsolation). If the big-picture model grows too many exceptions, then perhaps its time to toss it and just learn the small-scale rules. It's a weighting decision. I should also note that the flag model seems to work best for interpreted dynamic languages, not compiled ones. The '''flag model is a tool''', and like any tool has places where it works well and doesn't work well. PickTheRightToolForTheJob. --top ''As of yet, your 'flag model' doesn't seem to make any useful predictions, and seems too difficult even for you to apply to a language that you don't already know intimately. It's somewhat pointless to have a model of language behavior that can only be applied to languages for which you already know the small-scale rules. I think it reasonable to filter the 'models' we bother learning to those that have proven themselves useful. What makes you believe this 'side-flag model' is the "right tool" for any job?'' It does make predictions. The lack of a flag predicts that the value and only the value is what affects how operators react to it, and also predicts what operations the language is likely have or not have, such as a "typeName()" function. If you can't find a "typeName()"-like function, for example, then it increases the chances that the other flag-free patterns will be there. One can then verify that and have more confidence in understanding how to work with the language. As far as learning new languages, it helps one know '''what to keep an eye out for'''. And what is the alternative you propose? (for practitioners). --top ''I suspect an understanding of tagged unions (a class of variants, also 'inductive' types) would be sufficient to replace your entire 'side flags' model. And it would be accurate to both TypeTheory terminology, terminology in common use by users of at least ML, Haskell, and C, and often associated with physical implementation details in the obvious manner (tag+union).'' * Models choices are a good thing. Post it up here and let the readers select as they want. * ''Unlike you, I don't care about educating practitioners in TypeTheory. I've this idea in my head that most don't give a damn, and that those who do care will buy a book such as TypesAndProgrammingLanguages, which will teach them better than I've the energy to bother attempting. Most people believe in taking a BookStop and studying hard and putting their half-formed ideas through harsh tests before they feel well enough educated in a subject to teach others. I wish certain other people felt the same.'' * Most just want to use the flippen language, not go to math camp. The rest of my response would merely repeat existing practitioner-versus-theorist HolyWar material. --top * ''Ah, yes. I'll amend my statement. I am also ethically opposed to your "keep it simple for the masses" concept. People are better off uninformed than misinformed.'' * PageAnchor: Competitor_Practitioner * What is your suggested alternative to the flag model? The language documentation is not likely to use Reynold's models even if they wanted to go that route. Didn't I ask this before and you suggested one learn case-by-case specifics instead? My criticism of that technique stands. --top * [I'm not sure a trivial and incomplete "model" has any explicative value and may even cause confusion, but as a starting point, you could expand your "model" so that it's actually a model -- a self-standing set of structures, algorithms, etc., that can be used to explain the relationship between certain language statements, language behaviour, and type tags. As it stands, you've merely stated that "values have flags" and given a few trivial heuristics to unreliably detect whether "type flags" are in use or not. That isn't a model. At best it's an analogy.] * So you agree with me that, '''despite its current flaws''', there is not an equal or better competitor to the flag model for a practitioner? As far as producing "algorithms", it is not that kind of a model. It's the kind of a model that you apply to specific situations or training scenarios. -t * ''Of course we don't agree with that. At the moment, you can't even rule out ignorance as a decent competitor of the flag model.'' * You haven't shown any downsides to it, at least for the languages listed. But I also don't understand why you are being so argumentative. A reasonable person would say, "If it works for you, use it. If not, stop using it". '''You act like it will put somebody's eye out if they try it.''' -t * ''The downsides have long ago been mentioned, such as using terminology that will result in confusion when practitioners later study other languages. You haven't demonstrated any upsides to it, even for the languages listed. I don't understand why you are promoting this idea so heavily. '''You act like this idea is your baby and we're kicking it through the mud.''''' * How about find ways to resolve the confusion rather than throw the baby out with the bathwater? As far as defending this topic, it's turned into the primary battle-front for the bigger "war" of practitioners versus academics. The issues raised here often mirror related debates. --top * [The best way to resolve the confusion is to delete the pages making reference to the "flag model" et al.] * Is that supposed to be a real answer? * [Yes. I would give the same advice if someone proposed the "linked-list of array model" as an alternative to the RelationalModel.] * See "array-analogy" page-anchor. * [I have no problem with analogies described as such. I have a problem with analogies billed as models.] [It's not a "model" in the usual sense -- it's merely a partial statement of the fact that some dynamically-typed languages associate type tags with the internal representations of run-time values. Why redundantly use the term "type flag" to represent the mechanism commonly known in computer science as a "type tag"? By the way, your "model" doesn't make predictions. The predictions you're making are based on your own ''mental model'' of the type system under examination. There is nothing in the "flag model" that '''logically''' describes how the input of a given language statements can be translated into output consisting of specifications of behaviour.] If it reflects the actual implementation, that's a bonus. As far as the term, I felt "tag" is too overloaded with markup languages. If it really gnaws at you, we can consider a renaming plan. [Many words are overloaded. E.g., table, relation, set, etc... Using "flag" where "tag" is the familiar term really gnaws at me, in the same way that a database proponent using "relative" instead of "relation" would gnaw at me. That, and the inappropriate use of the word "model"...] No term makes everybody happy. Bunches of managers here are arguing over PowerPoint titles right now as I write this (along the lines of "Our Great Successes" versus "Our Great Solutions".). And your analogy is weak; "relational" is common both in academia and practice. Only professional language designers would be aware of "tag", not language users, of which there are far more of. You may disagree with my choice, but it is based on a rational weighing. [I didn't use the term "relational". Read what I wrote, please. My point is that there's no need to invent a new term for an existing mechanism when a perfectly suitable term already exists.] * We'd have to ask the author of "relative" why they did it to know if its a good decision or not. I gave my justification and don't see a need to repeat it again. I disagree with your logic complaint for reasons already given. We can logically compare what the flag model predicts versus what we actually see. If the predictions don't match either value (flag or no flag), then we can abandon or modify the model. How exactly is "model" "inappropriate"? [The three bullet points on TypelessVsDynamic merely specify how to (roughly, informally, and ambiguously, rather than rigorously) identify languages that might use type tags vs those that possibly do not. There is no specification of the logical connection between language characteristics and language behaviour. By way of analogy, a "model" that purports to describe how a car engine supplies power to the wheels (call it the "drive-pipe model") but only provides three bullet points that may, or may not, identify cars that use an engine, is not appropriately called a "model".] Your analogy does not make sense to me. Are you trying to identify poles or engines? Note that the 3 bullet points are not meant to be exhaustive. More may be added later. Also note that it is not necessarily meant to describe how languages actually work under the hood. It is a '''prediction mechanism''', not necessarily a model for "how". It is comparable to Newton's "laws" in that it makes sufficiently accurate predictions for practitioners to use, but is not necessarily the proper model under the hood (relativity is more accurate, but more cumbersome). [Poles? Huh? I still don't see how your "model" provides predictive capability without total reliance on assumptions about what your "model" means. That does not a model make, because the "model" only exists in your mind, not on paper (or Wiki page).] In general, I've found that languages that "act" like they have flags and act like they don't have flags are consistent. That is, the model is consistent for the languages I've used. None had a mix of some behaviors that looked tied to flags and others that didn't. They were all or nothing across the board (at least for scalars). True, its far from an exhaustive list, but a reasonable sample from a practitioner's perspective. If I did find an exception, that would not end the model's usefulness, but merely confirm there are exceptions. --top [Fine, but your '''description''' of the "model" does not address the relationship between language features and language behaviour. That relationship exists in your mind, but appears not to have made it onto a wiki page. Yet. Elucidate this relationship, and you'll be on the way to providing a model.] I don't know what problem you are imagining in your mind. I need more specifics. I cannot scratch your itch if I don't know where it is. [A model should be an abstraction of the real objects it represents, in sufficient detail to be used as a substitute for the real objects it represents, in order to be used to answer questions about those real objects in an '''automated manner'''. This may be provided by axioms, theorems and proofs. This may be provided by diagrams. This may be provided by algorithms. This may be provided by physical structures (e.g., a model ship, rocket, car, motor or aeroplane) that can be empirically (or mathematically) examined. In an analogical sense, your "model" claims to be a model ship, but it's only a ''picture'' of a ship -- there isn't any structure to your model (i.e., physical manifestation, diagram, algorithms, etc.) that can be tested in an automated manner. Note, for example, that the RelationalModel provides structures in terms of set theory, boolean logic, relations, tuples, types, scalar values and an algebra that may be tested and evaluated in an automated, logical manner. Your "flag model" provides no such ''written'' equivalent, yet it clearly exists -- you're using the structures that exist ''in your own mind'' in order to use your "type = side flag" equivalence to translate language statements into descriptions of language behaviour. However, you can't "show your work" for these translations ''in terms of your model''. With a complete model, you would be able to do so.] Automated? There's not enough scenarios to bother automating so far. How would automation to measure "relational" look? Again, you are not clear on what you are envisioning. And, the model does not necessarily have to reflect the actual underlying mechanism involved. Regression is an example of a modeling technique that can be quite accurate (if no "hard" edges), yet not reflect the actual mechanism in any way. ''Top... perhaps you should read what was written and avoid making such obvious mistakes in reading comprehension before putting the blame on others and calling their words 'unclear'. Anyhow: (1) Models should have sufficient details "to be used to answer questions in an automated manner". The ability "to be used in an automated manner" does not imply "must be automated". It only implies "could be automated". (2) RelationalModel is a model of data, not of "relational". (3) Models aren't properties, so the question on how "to measure 'relational'" is particularly senseless. (4) The explanation of modeling does not imply that models "necessarily have to reflect the actual underlying mechanism involved", so the related objections are moot.'' I find it poor writing. I've seen good technical writing and I've seen poor. Maybe you academic professionals are used to poor writing. Anyhow, the best test of "automatable" is showing it automated. Show it doing whatever this thing you imagine doing on "relational". It's your (pl) example, not mine. In other words, lets see an example of something doing the something that you want done to something (such as relational), and I will then show you how to do a similar something with types flags. And I would characterize "relational" as a set of operations, not a "model", although they are perhaps interchangeable. Type flags are a "model" in the sense that one can draw cubby-holes on a chalkboard and show how values and flags get changed as each statement is executed. It's a "mechanical" model, if you will. --top [By "automatable", though I do mean that a series of steps or transformations ''can'' conceivably be automated, there's rarely a reason to do so. What I mainly mean is that the mechanics of the model are '''sufficiently rigorous''' to be automated, and '''do not require assumptions'''. The usual mechanism for "automating" mathematical models (which your "flag model" is, whether you like it or not) is simply a human brain capable of reading statements of formal logic. I'm not sure what you mean by "relational", however, as it is an ambiguous term. Do you mean the RelationalModel in its entirety? Or do you mean the RelationalAlgebra component of the RelationalModel? I assume you're referring to the latter, as you're describing "relational" as a "set of operations", which appears to refer to the RelationalAlgebra. As for "type flags" being a model, as far as I can tell the whole of your model (thus far) is the following: "For every value V, there exists a related 'type flag' T." Okay, fine -- that's a good start. But what does that tell us? What are the characteristics of T that are of interest? Given some language statement S referring to some set of values, and some language behaviour B, how do S, B, and some set of (V, T) pairs relate to each other? And so on. These are the components of your model that appear to be missing on paper, but clearly exist in your mind.] Note that the relational example as an analogy to flags was *not* something that originated from me. Thus, I cannot answer questions about what was meant by it. * [Weren't you the one who wrote, "How would automation to measure "relational" look?"] * The paragraph right above that is what first brings it up. * ''The use of relational was an example of a 'model'. You claim your side-flags concept to also be a 'model'. There should be some similar properties between the two, such as the ability to perform step-by-step process to derive useful conclusions. That is, after all, what 'model' is all about.'' ** People use the relational model to organize information or perform queries, NOT to predict behavior. Maybe they could, but that is usually not what it's used for. Relational is a "blank slate" model, not a model to mirror another process/observation. Models can be used for different reasons. I will again point out that mathematical regression can generate models that are quite good at prediction, yet do not offer properties you listed for the relational model. -t ** [People use ''implementations'' of the relational model to organize information or perform queries, not the RelationalModel itself. The RelationalModel is used to predict behaviour about implementations of the model. For example, the RelationalModel may be used to determine the validity of hypothesised optimisation strategies.] ** Only if tied to an implementation. The relational model itself says nothing about underlying implementation. One optimizes an *implementation* of the relational model. ** [Not necessarily. A proposed optimisation '''strategy''' may be validated for correctness in the absence of any implementation.] ** How is "strategy" not "implementation"? ** [A strategy is a description of potential implementation. A proposed optimisation strategy, for example, is the following: "Where R is a given restriction (i.e., some WHERE clause) and T represents either a union, intersect, or minus operation, and p and q are relations, and C is a function representing cost of execution, given a query of the form R(T(p, q)), if C(T(R(p), R(q))) < C(R(T(p, q))) then replace R(T(p, q)) with T(R(p), R(q))." An implementation is the lines of code that make this manifest. The RelationalModel allows us to prove, without the need for an implementation, that R(T(p, q)) = T(R(p), R(q)). Therefore, we can be sure the optimisation strategy is valid.] ** You are using it in conjunctions with a model (abstraction) of implementation. And, it may be possible to cook up something similar for the flag model, er, flag analogy. Nobody has ruled it out. ** [I'm using what "in conjunction with a model of implementation"? What is a "model of implementation?" The above is abstract. Yes, it may be ''conceivable'' to "cook up something similar" for the "flag " -- in the same manner that a picture of a car might be the basis for creating a model car, I suppose. However, in the absence of such cooking, it remains -- at best -- an analogy or a reference to an implementation strategy.] * [Furthermore, the paragraph in question clearly refers to it as the RelationalModel, not "relational".] * I could ask if these are necessarily different things, but realized it would probably lead into a LaynesLaw ThreadMess on that alone. --top * [Then the relationship between the RelationalAlgebra and the RelationalModel is unclear to you. I suggest you read up on it.] * I didn't mention "RelationalAlgebra". * [So... Your reference to "relational" refers to... What?] * I did not originate relational of any kind as an example/analogy. So, why are you asking me? * [You used "relational" above no less than four times: 'And your analogy is weak; "relational" is common both in academia and practice.', 'How would automation to measure "relational" look?', 'Show it doing whatever this thing you imagine doing on "relational".', and 'And I would characterize "relational" as a set of operations, not a "model".'] * If it's not important to the central issue, let's drop it. * [What? And lose sight of your rollicking incorrectitude?] * Incorrectitude? Going Bush on us now? [Using the relational model, we can determine interesting results. For example, it can be shown that if R is a given restriction (i.e., some WHERE clause) and T represents either a union, intersect, or minus operation, and p and q are relations, then R(T(p, q)) = T(R(p), R(q)). This is a very useful result for implementing query optimisation, because it says that given a SQL-ish query like (SELECT * FROM p UNION SELECT * FROM q) WHERE x = 1, we can internally perform the WHERE on p and q individually before performing the UNION, with a potentially huge performance increase over the original. The proof of this is left as an exercise for the reader, but suffice to say both its determination and application are automatable, given the elements of the RelationalModel: set theory, boolean logic, scalar values, tuples, types, relations, and relational algebra. Can you use your "flag model" to find similar interesting results?] You guys are trying to over-complicate this. I am not trying to do "interesting math" with the flag model. It can be used to explain the behavior of common dynamic languages in a mechanical kind of sense. * ''How?'' * It would be difficult to demonstrate without a physical chalkboard demonstration. Maybe when I retire I'll make a Flash demo of it. Chalk-Stop :-) Maybe I can create a step-by-step ASCII transition view. I'll ponder that. * [This response, more than anything else, sums up the problem with the "flag model". I.e., it isn't a model, but will become one as soon as Top is provided with a suitable chalkboard. In the mean time, I suggest it be downgraded to the "flag notion."] * How about we look at it from this perspective: how would YOU describe the difference between the 2 "kinds" of languages to a newbie? In school, the instructors I remember would draw boxes on the chalkboard to represent variables, go through each statement one at a time and show how the content of the boxes changes. In some cases they'd use binary, or just written values in other cases, depending on how low-level they were explaining. Now, I don't remember them ever demonstrating type flags this way (such as a 2-part box), but it is similar to this technique. I assumed everyone with a degree is familiar with this "box" teaching technique. It was common with array demonstrations. --top * [Boxes and lines are a universal pedagogical technique. I informally tackle such issues by discussing value representations and types in statically-typed languages like C#, Java, and C (which the students know already), then talk about weakly-typed languages with a variety of value representations (e.g., assembly language & Forth), then discuss "mono-type" languages where values are represented as strings (e.g., old Tcl), and finally introduce dynamically-typed languages with a variety of internal representations. These are all described in terms of value representations and language behaviour, though with the last one I introduce type tags as an implementation mechanism rather than a model.] * You guys seem inconsistent about model versus implementation. If its an implementation, then why are you complaining about lack of details since those languages already exist and are inspect-able as OSS interpreter implementation code in many cases. Plus, '''described as an implementation or a model does not really matter''' for most language users. They just want to "understand" why things behave as they do. Thus, the distinction between implementation and model is of no real concern to them. I put "understand" in quotes because it is not necessarily about understanding implementation. It's more in terms of prediction. Prediction techniques don't require knowledge of implementation, as the (math) regression example already illustrated. Prediction is usually sufficient for them; knowledge of implementation is merely a bonus. --top ** [I'm not complaining about a lack of details in language implementations that use type tags, I'm complaining about the lack of details in your so-called "model".] ** Didn't somebody above state that some actual implementations use type flags? If so, there's an implementation you can study if you wish. ** [Yes, some implementations use type '''tags''', but my problem is with '''your "model"''', not the implementations. Your "model" is incomplete to the point of being a mere analogy, and it's only really applicable to the limited set of languages that use type tags. Hence, I see little reason for the "side flag model" to exist.] ** What's wrong with it being applicable to a limited set of languages? Fairly common ones, for that matter: Perl, VB, PHP, ColdFusion, JavaScript, TCL, among others. '''Just because it may not be universal, does not mean its useless.''' -t ** ''Limited applicability of '''any''' model reduces the value of knowing it. So does having limited predictive power... which, for flag model, was likened to a mere analogy. Having both of those conditions at the same time is a double-whammie - it's hard to see much value left in 'flag model' after those blows.'' ** When I see your lovely alternative, maybe I'll change my mind. -t ** ''When I see a more useful model, maybe what's in your mind will matter to me.'' ** So you have none. And again, others have mentioned that some existing languages actually use flags/tags under the hood. That is NOT in my imagination. -t ** PageAnchor: array-analogy ** [What some existing languages have done is use tags under the hood to implement various models of type theory, if even on an ad-hoc or inadvertent basis. Your "flag model" can, at best, only be considered an analogy, or a minimal description of an implementation strategy. As has been pointed out, it is not a model, any more than a linked-list of arrays (i.e., an implementation strategy for creating tables) can be considered a "relational model".] ** If imagining tables as linked-lists of arrays (or maps of maps) helps them work with the technology, then why the hell complain? People use all kinds of mental metaphors, especially when first learning something new. They may not always be 100% perfect, but simply learning case-by-case details is not an option for all but the very few with photographic memories. If you aim to end that practice, you need to suggest a practical alternative. ** [Such imaginings are then properly considered analogies or references to implementation strategies. They are not models. Use of such things as illustrations or analogies is fine, '''but they are still not models or theory, and it only causes confusion to treat them as if they are.'''] ** You are probably wrong, for the boundary between analogy and model is fuzzy. But, I don't wish to do the LaynesLaw dance over "model", at least not under this topic. '''"It" is useful, regardless of how you classify it.''' -t *** ''You have yet to demonstrate that last statement to the satisfaction of any but yourself. Is self-satisfaction enough to shout it in bold?'' *** My anti-fans will always be dissatisfied with whatever I say. That's the life of a sacred-cow critic. Plus, you still have not given an alternative, only hand waving. *** [Sacred-cow critic? You? You are a legend in your own mind. After years of working in computing education, I see no need for an alternative to your "flag model". It's a non-model without a point. I note a staggering lack of support for it here, for example. Is there support for it ''anywhere'' outside of yourself?] *** Where is your survey? You and "brackie"? Knowing your style, I don't think I'd grade you as a very good teacher anyhow. You are probably one of those fuddy-duddy's who gets the job because they know a lot of trivia, NOT because they can actually teach. *** [Nice ad hominem. Where is your evidence of support for your "flag model"?] *** And "legend in your own mind" is not a personal attack? Hypocrite! *** [It's a statement of the obvious. I make no claims to being a good teacher, theoretician, or anything else. You, however, claim to be a slayer of sacred cows, though the evidence obviously demonstrates that you are not. You apparently think you've created a model for the masses, but again, no.] *** Let's '''let the reader decide'''. The flag concept has worked for me. *** [Then your hypothesis is that the flag concept might work for others, yes? In the interest of good science, then, perhaps you might devise a well-controlled, objective experiment to determine whether or not -- or to what degree -- your flag concept is of value?] *** ALL potential models and/or teaching methods for type behavior should ideally be tested. *** ''Promising models of type system behavior usually are tested, though I'm unaware of any evaluated based on how easy or difficult they are to teach. Maybe they should be, at least for production languages. More often they're tested for utility... the ability to make predictions and promises that someone has deemed useful enough to pursue, often to push for improved automated optimizations or reduced specification while maintaining safety.'' *** I'll favor teach-ability to the "masses" of programmers over 100% accuracy or rigority of the model. I can explain to a student using the tag model why one can know that the CF version of "isEmpty" works in the ColdFusionLanguageTypeSystem example and why it's simpler than both the JS versions. You can't, at least not without piles of ivory tower notation, which will make the typical student run out screaming. ** [The boundary between analogy and model is not fuzzy, at least in this case. If it is useful to you, then you might consider authoring a page describing the pedagogical value of considering type-tag based implementations in terms of understanding how certain languages handle types and values. That does not, however, make the application of type tags into anything resembling a model.] ** It would be satisfying to bet money on it and watch you lose your shirt. At this point we'll just let our differences stay differences and hopefully wrap it up. -t ** [I'd rather bet on it, actually. I like winning money.] ** Watching bloated egos eat crow can be far more satisfying than money. ** [You apparently don't understand what a mathematical model is. Your "model" is implicitly mathematical by its context -- the computational domain. A mathematical model consists of (at least) a set of variables, i.e., the inputs/outputs to/from the system -- in this case presumably expressions and/or statements in a given language and descriptions of behaviour -- and equations that describe relationships between the variables. Where are these in your "flag model"? (Enjoying that tasty crow?)] ** I didn't say "mathematical" model. Natural selection is a concept that didn't start out as a mathematical model, yet most still considered it "a model" at that time. ** [You may not have ''said'' "mathematical", but it is -- by virtue of its context. In the computing domain, any model is inherently mathematical. Natural selection is not, nor has it been considered a model. There are, however, numerous models ''of'' natural selection. The distinction is significant. Furthermore, a model must have structure. Your "model" has essentially none, bar a single axiom: Every value has a type flag.] ** Huh? Not every language uses type-flags (or acts like it uses them). Perhaps you have misunderstood the entire thing. ** [*Sigh* Let me rephrase that: Your "model" has essentially no structure, bar a single axiom: Every value might or might not have a type flag. Better?] ** Generally *every* variable (at least scalars) either has one or doesn't have one. I've never seen mixed (although using "variant", "object", or "unknown" types may emulate a mix). It's not about "structures". Its a model of variable representations. You are just being nitty for the sake of being nitty. ** [No, I'm being "nitty" for the sake of scientific rigour and accuracy. However, this confusion no doubt owes much to the fact that your original description has become buried in debate. I am going to resurrect it in the next section below (see PageAnchor "T''''''ypesAndSideFlagsDescription") and edit it to remove or appropriately alter the contentious material, hopefully leaving an acceptable core. We can edit said core until everyone is happy, copy it to TypesAndSideFlags and refactor the remaining pages to remove the cruft and debate. Sound good?] ** Maybe some things are more important than "rigor and accuracy", such as communication in order to use tools of the trade without spending 200k on yet more of your pedantic "education". You are biased into justifying your expensive shit. Ego and self-preservation is blinding you to practical issues. * ''Modeling in terms of an approach to implementation is a relatively easy way to teach both a model and how it integrates with the 'real world'. It's important to distinguish properties of the given implementation (such as specific algorithmic complexity and storage costs) from the 'necessary' properties of the model being implemented, but most people don't find such discussions enormously challenging; I'm no psychologist, but I suspect it is easier for most people to abstract details away from the implementation than it is for them to understand a model without observing it. In an implemented model of type tags, you can very likely show how such a 'tag-based' approach crosses storage, serialization, input syntax, and interaction with operators.'' It is for practitioners, not math gurus. If it can be repackaged for math gurus, I don't know. It's not one of my goals. [With my practitioner hat on, looking at "values have (or do not have) type flags", I can't see how that explains language behaviour. Obviously, it does in your mind, but without some clear written elements to your "model", I'm afraid it remains locked in your mind and inaccessible to the rest of us.] ----- '''PageAnchor: T''''''ypesAndSideFlagsDescription''' The following is a pedagogical tool which may assist students of certain programming languages in understanding some aspects of language behaviour, and is also an actual run-time or compile-time mechanism used by some language implementations: Given a value or variable, its type can be indicated by an associated tag (aka "side flag"). In other words, every value or variable is a dual-cell node where one side of the node is a value or value container (aka variable or slot) and the other side is a single type indicator (tag) or a collection of type indicators. The tag(s) identify the value's type, and are used to decide how the value should be used. * ''But this doesn't help anyone because instead of saying it has an associated tag, you could just say it has an associated "type". Kids and students learning programming already know what types are, so they don't need to be confused and told that types are flags. They know what types are from looking at the fruit bowl and distinguishing between different '''types''' of fruit. They also know what types are from math where they learned integers and such types. For those without such basic education, they are doomed in the programming field. EducationHasFailed or EducationIsFailing.'' * Yes, we know it as a kind of vague notion, but that's not good enough for the trickier questions and borderline issues surrounding types. Note that: * "Variable" is taken to mean (for example) X in an assignment statement like "X = 7", not "flexible sized". * Variables may have more than just values and type tags. There may also be indications of length, scope, etc. as needed by the implementation. This description does not dictate how the type tags are actually used, only that they exist and make a difference in implementation behaviour. That is, if the values of the type tags are changed, the behaviour can potentially change. For this to be useful in terms of understanding language behaviour, we need to know specifically how the tags are used in a given language implementation. For example, in a hypothetical language implementation where type tags apply (as described above), a value represented internally as the ASCII string "1542" will be treated as a character string if its tag is STRING, treated as an integer if its tag is INTEGER, and treated as a floating point value if its tag is FLOAT. Therefore, given the following variables: a = 1542 (where a's tag is STRING) b = 1542 (where b's tag is INTEGER) c = 1542 (where c's tag is FLOAT) // comments about the example moved to its own section below. The following behaviour may be seen: WRITELN a + a; 15421542 WRITELN b + b; 3084 WRITELN c + c; 3084.0 In this example, the '+' operator uses the type tags associated with its operands to determine its behaviour. Note that the above does not and cannot predict the result of, for example, WRITELN a + b. --AnonymousDonor That is not necessarily true. ''It is true. What is written above (hence the phrase "note that the '''above'''...") does not and cannot predict the result of WRITELN a + b. What is written below, however, apparently can. It must be noted, however, that what is written '''below''' is ''not'' '''above''' that which is written '''above''', so the statement '''above''' is '''necessarily true.''' '''REFACTOR THE ABOVE IF YOU DON'T LIKE IT, YOU ARGUMENTATIVE BASTARD, AND STOP WASTING OUR TIME WITH CRAP'''!'' * It was either misleading or ambiguous. What is wrong with pointing that out? It is an on-topic correction also, not about who insults more or whatnot. I didn't want to refactor it because I might be accused of "changing other people's text without their permission". If it was older text, I might have. I generally don't change other's fresh text. * ''What do you mean it's misleading or ambiguous? Given what precedes the statement, it's '''true'''. The intent is to edit the above. Did you not read the bit where I wrote: "However, this confusion no doubt owes much to the fact that your original description has become buried in debate. I am going to resurrect it in the next section below (see PageAnchor "T''''''ypesAndSideFlagsDescription") and edit it to remove or appropriately alter the contentious material, hopefully leaving an acceptable core. '''We can edit said core until everyone is happy''', copy it to TypesAndSideFlags and refactor the remaining pages to remove the cruft and debate."'' * "The above" is ambiguous because one does not know if you are talking about a hypothetical language, or "rules given so far". (I originally interpreted it as the first.) As far as refactoring the page, I'd suggest create a parallel page first and work on that. That allows people to compare to original. * ''"The above" referred to the content ''above'' where I wrote "above", but anyway... Perhaps this is time to copy this section to TypesAndSideFlags with the discussion removed and the content below incorporated as you see fit.'' * I'd suggest saying "Using the information given so far..." instead of "The above" and making it clear which noun "cannot predict". As far as moving it to TypesAndSideFlags, someone objected to "flags" and want "tags" instead. Personally, I don't like "tag" for reasons already given, but I'd suggest we reach a consensus of the title first rather than have that ugly title-battle again. (Now I know how a Middle-East negotiator must feel.) --top * ''Your suggested changes sound fine to me, but I'd '''vastly''' prefer "tag" to "flag", since the term used in the literature for implementations of the concept is "type tags" and because "flag" generally implies a boolean value.'' * "TypesAndSideTags" ? * ''How about "TypesAndTypeTags" ? * "TypeTags" ? Some languages may have rules of type precedence. For example, the "+" operator may have a rule that if at least one operand is numeric (such as int or float), then it attempts to execute math addition, parsing any string operand as numeric. Another language may have "+" assume the type of the first operator. Thus, "print(a + b)" would assume type STRING, because that is a's type tag. Languages that lack type tags (or downplay tags or act like they don't exist) usually do not have ambiguous (overloaded) operators. "+" would always be math addition, and another operator, such as "&" or "." is string concatenation, for example. --top ------------- '''Making Predictions''' It has been claimed that the flag model "makes no predictions". I counter this by saying I've never found a language that "violates" the 4 "rules" listed in TypelessVsDynamic, under heading title "Testing For Flags". If it passes one, it always passes all four. This is an impirical observation, not a mathematical/logic one. If we find exceptions, we can either list the exceptions, or revise the model. -t ''A set of empirical observations may be used to validate a component of a model, but what is lacking in your "model" is that component -- an equation (or set of equations) that represents the relationship between language characteristics and language behaviour -- which could be validated. The equation obviously exists in your mind, but has not been written down. The 4 "rules" you've listed appear to ambiguously detect type tags, and thereby serve as a partial test for whether or not the "model" applies, but they are not components of a model itself. It's like defining "if stuff falls, you've got gravity" as a test for the presence of gravity, and then claiming that "stuff falls" is a model of gravitational forces. In short, at best you've established a correlation between your observations of certain languages and your tests to see whether certain languages fit your observations of certain languages!'' I've never seen that done for any language. For example, could you write a mathematical equation or algorithm to detect whether a query languages is RelationalAlgebra? (IIRC, nobody could build an automated type-presence detector either, because the definition depended on "intent".) -t ''That's an interesting question; off the top I'd say it's non-trivial but theoretically possible, but only given a large number of significant constraints on the inputs. Without constraints, we'd be forced to consider expressions in my newly-invented (as of this sentence) language Splorp, where queries consist of random line noise where ASCII characters are bound to RelationalAlgebra operators by a random number generator. However, I'm not sure it's entirely relevant here. It would not be a model per se, so much as an implementation of a language parser and a collection of tests. Models are, however, used throughout computer science. Of relevance here -- as an example of a useful ComputerScience model, and one that your question reminds me of -- is that for finite state automata. See http://en.wikipedia.org/wiki/Finite_state_machine, in particular the "Mathematical model" section.'' ----------- Judging from the roundabout way that Top discusses it, I summarize his 'model' as follows: ''"Look, you stupid moron practitioners whom I believe incapable of understanding types! In some languages, you can ''view'' values or objects have two parts! When this happens, one part, which I call a 'flag' even though it is commonly known by you guys as 'tag', is used to interpret the other part and thus understand the whole value! Operations in the language do the same - they use both parts of the value to determine how to operate on it! That's all there is too it! Oh, and since I'm so arrogant, I'm calling this 'the side-flag model of type implementations!' even though the academics will crucify me for abusing both "type" and "model"! I'd prefer you call it a definition of 'types'! If we all work together we can change the accepted definition of 'types' and show those stubborn academics!"'' So... am I missing anything? ''I've never called myself "clever". You are just envisioning that because of your bias against me. You view me through demon-colored glasses, and picture behaviors that never actually happened. --top'' Ah, sorry. I'll correct it to "arrogant", which I know you've called yourself. ''I did? Nevermind, don't want to take issue with that.'' ----------------------- Comments from example above: a = 1542 (where a's tag is STRING) // but why not just say a's TYPE is STRING, b = 1542 (where b's tag is INTEGER) // but why not just say b's TYPE is INTEGER, it is more clear! c = 1542 (where c's tag is FLOAT) // ... TYPE is float! not tag!! Saying "it is a" tells us little about what's going on under the hood. ''Likewise, saying types are flags tells us little about... because "are a" and "is a" don't tell us much nor provide a model. '' As a vague notion it might be "good enough" in some cases, but may not be sufficient to answer more complicated type issues. The stickier the issue, the more one needs a concrete "mechanical" model to both mentally model it and explain it or communicate issues to others. ''What goes on under the hood in a mechanical car may be different between different brands of cars. PHP may use C structs (tags) at some point to store information about some value that was parsed, and it may or may not throw away this struct and start up a new struct later... I don't see why knowing this would help a person choose a good programming language. I'm not going to choose PHP because they did or did not use throw away structs (tags) at one point in time to track type info or to ensure that two numbers can be added together. What baffles me is that the "tag free camp" seems to think that choosing a language should be based on whether tags are used or not. A better programming language apparently (laughingly) is a "tag free" or "type free" language. This seems to be saying that "missing information" is better than having type information. The less information you have on types, the better. I don't get this, and it almost seems like it's some kind of troll joke.'' "Under the hood" is perhaps misleading. What I mean is a model that "explains" what is going on with the programming language. In other words, "why is it behaving like it does"? Now, I don't expect it to mirror the ACTUAL implementation, for languages should not be defined by implementation, but by how they behave. The model can be a UsefulLie as long as it facilitates prediction and "understanding" in a planning and debugging sense. And it's not just about choosing a language, but also about knowing how to work with it. As far as the value of tag-free languages, I personally find them better than tag-based dynamic languages for many domains because you don't have to consider both parts (type tag and value), just one part of a variable. It's more WYSIWYG. I haven't seen the alleged benefits of tags explained with realistic scenarios. Show me the wonderful things tags help me do and you just may sell me on the idea if they outweigh the downsides. {That doesn't even make sense. Could you please rephrase your comment using recognised ComputerScience terminology?} What doesn't make sense? Please be more specific. And where is the official ComputerScience dictionary? And why is terminology from say Economics excluded? {What is a "tag-free" language? I find no mention of "tag-free languages" in the Literature (peer-reviewed journals and popular texts), nor do I find any rigorous explanation of "tag-free languages" (versus, I assume, "tag languages") here. You may find it helpful to confine yourself to terminology from the ComputerScience dictionary at http://www.oxfordreference.com/pages/Subjects_and_Titles__2D_C01 } I've explained in other topics. As a working definition, it's a language that behaves as if scalar variables are implemented as strings and only strings, with no detectable "type" tag or indicator (outside of the printable string). Operations parse the strings as needed into other "types", such as numbers. {"It's a language that behaves as if scalar variables are implemented as strings and only strings" and "operations parse the strings as needed into other 'types', such as numbers" makes a certain amount of sense. The reference to "detectable 'type' tag or indicator" loses me. It would be far more helpful if you'd describe the behaviour you're seeing, rather than speculating on the nature of the implementation. It would be the same if you were trying to describe a problem with your car: Far better to say that there's a rattling noise under the hood when you accelerate, than claim "it behaves like the dangling rod has fallen into the swiveling wheel," knowing full well that "dangling rod" and "swiveling wheel" are your own personal descriptions.} Sometimes using an analogy of another sound source is easier than trying to recreate it with your own lips. ItDepends. "It sounds like a cow-bell in a cement mixer" is likely more accurate than most of the population can simulate with their own mouth and more descriptive than "rattling sound". Your particular physical analogy example just happens to be a crappy choice, I have to say. There's good models and bad models. A "fake" model can still be a good model if it does what it intends to do. (Taken too literally, it might backfire, but that's life. Use the tool for what it's intended for only.) "Example Debra" under JavaScriptSucks gives a situation where there's a "detectable type tag". A "print" statement (or conversion to string) is not enough to describe/predict the behavior of a variable. There is another "element" not revealed by a print statement (or string conversion) that affects behavior. If a variable (or model of a variable) contains only a string value and no "tag", then '''if two variables have the same printable/stringable value, then they always behave the same'''. This is not what Example Debra shows. It indicates a "hidden" element or attribute that is not directly observable (printable). In tag languages you'd usually have to print/display both the value and the type indicator to predict behavior accurately: printLine("value of a: " . a); printLine("type of a: " . typeName(a)); // (period is assumed to be string concatenation) Tag-free languages don't have the equivalent of a "typeName" function. They may have operations such as "isNumber", "isDate", etc., but these only tell you that a given variable is parse-able as a number, date, etc. But it never violates the print-same-behave-same rule highlighted above (per experiments or documentation). If you have a better way to describe such behavior without assuming a 500-page thesis, I'm open to suggestions. Note that under the hood, a "tag-free" language may still use tags for efficiency purposes. However, its behavior would be identical to a tag-free implementation of the same language under a different compiler/interpreter (but maybe slower). In other words, we could clone the c/i without using tags for implementation. The tag model primarily intends to model behavior of the c/i (language), not necessarily the implementation. ----------- '''Expression Comparison''' Here's another way to think about the usage of the side-tag model. When programming professors are describing "how" computers evaluate expressions to newbies, they may offer a model that produces the correct answer, but probably doesn't actually reflect what the compiler/interpreter is doing under the hood. It's a model to facilitate "understanding" and prediction, not to reflect the actual guts. The professor may start out, "scan the expression from the left to right until you encounter a closing parenthesis ")". Put your pencil tip on that parenthesis. Then move your pencil leftward until you encounter an opening parenthesis. The underline represents an expression that we'll call E. Evaluate the expression E based on the operator priorities listed on page 123 of your textbook. Then replace E, including parentheses, with the reduced expression, and repeat the above steps for the next set of parentheses...." --top -------- Is it a model, merely an analogy, or both? ''Actually it is just a silly metaphor, IMO.'' {It's a tool. A useful tool. What category of tool it is, well that's a LaynesLaw mess. -t} ------------ See also: ColdFusionLanguageTypeSystem, TagFreeTypingRoadMap ---- CategoryLanguageTyping, CategorySimplification JanuaryZeroNine