Type Relation Comparison

This is an analogy or structural comparison of types and relations.

It is intended to make the concept and application of types clear if you are already familiar with relations (data-base wise).

If a type corresponds to ("<->") a relation, then (quoted parts from Wikipedia):

Type <-> Relation
- A type constrains the possible values of a variable
- A relation 'constraints the possible values and combinations of values' [in a DataBase).
- ...so both types and relations specify constraints.
TypeSystem <-> DataBase Schema
- 'A type system associates a type with each computed value.'
- '[A] database schema is a set of formulas (sentences) called integrity constraints imposed on a database.'
- ...so both define the overall system.
Value <-> Tuple
- 'a value is an expression which cannot be evaluated any further. The members of a type are the values of that type.'
- 'A tuple is an ordered set of attribute values.'

See http://en.wikipedia.org/wiki/Relational_model, http://en.wikipedia.org/wiki/Type_system

I don't see how the above is intended to clarify types for Top, given that it's unlikely to make much sense to anyone else. I'm very familiar with "relations (data-base wise)" and "the concept and application of types", having implemented both the RelationalModel and DateAndDarwensTypeSystem in the RelProject, but I find the above baffling. For example, a relation is not a type -- a relation is a value. A relation's heading, however, is a type. A tuple is also a value (and a tuple's heading is a type), but I don't see why tuples are chosen in particular to illustrate some "corresponds to" relationship with values. "TypeSystem <-> DataBase Schema", I don't get at all.

Interesting. I thought the analogy quite obvious. Especially after looking up the wikipedia entries. I assume that 'relation's heading' is usually meant when talking about relations and what you call 'relation' is simply the table. And I chose the tuple because it is the obvious kind of value on that side. I intentionally left out the comment that a relation is a special kind of type to avoid bias.

But if you cannot see the analogy on that level, probably Top cannot see it either. So if you think this page doesn't help. Please feel free to delete it again.

{Let's not delete it. It's an example of differences in the perception of "types", and limits of Wikipedia. -t}

I suspect my interpretation of types, and the original poster's, are essentially the same. So I don't think it's an example of the differences in the perception of "types", nor does it highlight limits of WikiPedia. I simply think that whatever the original poster's intent, it's very, very poorly expressed via nothing more than WikiPedia extracts and excerpts. Far, far, far better would be a clear and lucid explanation for each "corresponds to" relationship, in the author's own words and supported by examples, and (perhaps) including (but not relying upon) citations from WikiPedia for support.

EditHint: eventually move this section below because it's not about relations. Perhaps back to DefinitionOfTypeTag.

Re: "A type constrains the possible values of a variable"

No, it doesn't necessarily do such. For example, two sequential bytes can be made to represent both a string (or character set) or an integer. It doesn't have to constrain the content of those two bytes in any way. Types may govern how they are interpreted, but that's another matter. - top

Yes. If you do disagree with that, then I cannot help. I didn't cite wikipedia for nothing to make this analogy as clear as possible. But I hope you agree that relations constrain something. Please consider a constraint on the same level of abstraction.

I refute the idea that types are about "constraints", and instances of usage by others suggests this is the case, especially in dynamic environments.

But that's the core of the concept of types! You seem to be more interested in the usage of types (e.g. for dynamic exection), where the consequence of an expression having a specific type 'causes' specific interpretations. But to have these specific consequences one needs to understand the conditions for it first, or?

The consequences are specific to a language/api/app. In the tag model, the tag may indeed affect how the value is interpreted or used. But that's still specific to the domain/language, etc. We could perhaps say that the value of the tag must SOMEHOW affect the result, because if it didn't then it would produce results identical to a system that didn't use/have the tag. But I wouldn't want to embed the definition with "how" it impacts things other than an impact happens. "Constraint" is too specific. -t
Indeed, a tag allows to affect how a value is interpreted. It doesn't say anything how it is interpreted (that is left to the specific language). But it also doesn't say how the tag is 'set'. One could say that the tag model is an operational specification of an interface between a type system of a language and the dynamic semantics of a language.
How it's "set" is also language-specific, but the tag model can usually model each situation. The VB.net example given allows both an explicit declaration, "Dim Foo as String", and implicit declaration such as assignment using quotes (Foo="123") if declared as an object (aka Variant). But at least the model can be used to illustrate/simulate concretely how such would happen as the program is starting and/or running. One can point to something specific on a chalk/white-board and show exactly what changes when and where while running through a scenario. -t
And it's not just about interpreters. Compiler behavior can also be modeled with the tag model. It's just that the compiler "gets rid of" the tag at an earlier stage. It may be possible to have a C interpreter that produces identical I/O results to a compiled version, just slower; but, I haven't tested that in practice. Thus, the distinction between a compiled language and interpreted may be more about "staticness" than about the compile stage. In such languages, once a type tag is set, it's more difficult to change. Most common languages fall into one of 3 categories: those that don't allow a variable to change it's tag, ones that do, and ones that don't use tags to begin with (at least act like they don't use). -t

Re: "a value is an expression which cannot be evaluated any further."

So if I store (dynamic) expressions in strings, they are no longer strings?

Again I cited Wikipedia for clarity. What is a value for you?

If the def has flaws, it has flaws.

Contributors: GunnarZarncke

CategoryComparisons