Constraint Type

See Instead: PredicateTypes, rather than the rant below.

But that page talks about instances, properties, objects.. and I want little to do with that. AntiCreation.

Your objection seems to be irrational. Perhaps you can explain how columns, fields, and cells - mentioned below - are not carrying instances?
The computer science definition of an instance is class/object related. I'm talking about restraining any sort of variables whether they be classes or not. If we want to stretch the definition of instance to mean "anything and everything that is anything" then this is a different definition that doesn't go by the standard one.
There is no single 'computer science definition of an instance'. There is one used in the context of object-oriented programming, but 'instance' can (by context) also refer to instances of variables or values or databases or messages or, indeed, "anything and everything that is anything". And PredicateTypes apply, indeed, to anything and everything over which you can mechanically apply a predicate - which usually means a value or structure held by a variable.

I'd rather call it "validation", not "types". But, that may then trigger another HolyWar about the definition of "types" if we try to get into the meat of the difference.

Validation is a process; types are, trivially, not processes, and therefore anyone who would rather call types 'validation' is someone who would rather be wrong than accept trivial truth.

But there can be declarative validation also. For example, storing a RegularExpression in a DataDictionary.
- That isn't validation. Validation would be when you take that RegularExpression, test it against the entries of a column, and say of those entries (or of the column as a whole) whether they are 'valid' or 'invalid'. And doing so is a process. The RegularExpression, in such a role, is a declarative 'constraint', but merely placing it into a DataDictionary validates nothing, nor does it initiate a process of validation (unless, of course, your DBMS uses a triggering system to automatically start validation when the DataDictionary is updated... but then it is the trigger mechanism that initiates validation; the RegularExpression just sits there).
- If you want a better understanding, perhaps think of 'types' as the descriptions of what is valid or invalid whereas 'validation' corresponds to the active process of checking whether things are valid or invalid. Descriptions can't 'do' anything... all they ever do is just sit there; it takes an interpreter to 'do' something. This description and the interpreter are related formally in language type systems by describing, formally, how the descriptions (the types) affect the validation process (the typecheck). Whether that check be static or dynamic or soft is immaterial. In this sense, a RegularExpression is not necessarily a type, but it can be a type if you stick it into a DataDictionary and there is some formal relationship between sticking a RegularExpression into the DataDictionary and the process of validation (i.e. "if a regular expression is in the DataDictionary, it requires that the contents of the associated column be strings and that the RegularExpression evaluator result in a success-state when applied to the string." - an instance of PredicateTypes.) If there is no formal relationship, then the RegularExpression might as well be line noise, and certainly wouldn't constitute a legal 'type'.

Consider that this isn't necessarily a page about computer theory and academia.. but rather.. think about real life. Why type of car do you have? One that has a 5 speed gearbox limit? Does it only reach 200mph? Is it the one that is red? A type is just a label for "some kind of thing". I consider a type anything that can be described differently than something else.. and the dictionary agrees. All the TypeTheory talk seems like a bunch of over analyzed lightbulbs to me. What type of light bulb is that? 100 watt or 200 watt? 60 watt? Let's not overanalyze the hell out of types. Keep it simple.

Re: "All the TypeTheory talk seems like a bunch of over analyzed lightbulbs to me." - That's the kind of talk that launched the last Types HolyWar.

{You're keeping it "simple" by dismissing the complexity implied by "described differently". The multitude of ways to describe "differently" -- and to gain power and expressivity in such descriptions without losing validity and/or acceptable performance in implementations -- is the basis of TypeTheory. Don't make the mistake of regarding TypeTheory as mere academic navel-gazing because the domains with which you're familiar do not appear to demand sophisticated type systems.}

Sophisticated type systems are in languages where you can define your own types.. which I work with (esp. strong/static type systems). The issue of simplicity is implementing it. I know exactly what I want, but it may be hard to implement. Implementing a framework/system that is simple is very hard at times. Much easier is to implement something complex and hard to use. What I want is a type system that is less computer oriented and more human oriented. Some type systems put too much emphasis on the CPU, such as when one defines a "byte" instead of defining a range of 0..99 or 1..100. One thing that bothers me is that NiklausWirth took out the constrained ranges in some of his languages later on.
- Not all languages where you can define your own types qualify for the title 'Sophisticated type systems'.

I'll add: only the naive believe they can 'keep' something simple before doing enough analysis and exploration to 'get' it there in the first place.

It would also be nice to constrain types to miles and celsius rather than say integer or byte. This can partly be done or emulated using objects or records or structs.. but we want to brainstorm ideas on this page on how to make constrained types more useful.

Been done. See FrinkLanguage, which has PredicateTypes. There are also Boost libraries for it in C++. I'd like to see it done more effectively in more languages, though.

Databases usually do not let one define many types, they just give you some fixed ones. This is partly for practical reasons, as we can't extend everything to the perfect ways we want. It is possible databases (and/or languages) just need to give us at least a few more fixed options that are missing right now.. and we might do okay with that. And/or an extension system with our without it.. might be useful (but then premature optimization fans will see a problem here).

Databases could give considerably more complex types and still be practical, but the cost is a considerably more complex query language. Some people (who wish to remain anonymous but have very arrogant handles on this wiki) rail against the idea of types because they think (mistakenly) that they harm interoperability. Experience with systems like XML and even the standard 'schemas' and well formatted files like CSV have repeatedly proven the contrary, but reality very rarely interferes with a stubborn viewpoint that can't be forced to face reality.

If we just keep everything as a string and validate it with a regex (or better, a plugin parser function)... this is a constraint, and is related. so I will not argue that validation is something completely different than a type. Of course types go through validation. The page title was just thought up and was not meant to aruge whether a type contains some sort of validation or not. Types that are strong at compile or run time are of course validated and validation is related to typing. Type systems can save the programmer from reinventing checks in his algorithms each time. Hopefully with a type system this leads to less software bugs and even more focus on unit tests that don't try to reinvent the type system by unit tests.

A problem with programmers and our current type system is that we are stuck in this mode of thinking that binary is GoodEnough and that everything is a 1, 0, 8, 256, 32, 1024, etc.

Let's abstract away from that or wishfully hope for a decimal based CPU. BinarySucks?. TwoFingeredComputer.

Or there is the boolean and null issue. True and False are a nice constraint.. but null? Is null a constraint? Or is that just stupidity?

We need constraint oriented types... such as ranges, limits, restrictions.

Maybe there are types.. but they need to be constrained in manners different than our current (brain damaged) type system.

Programmers should not be thinking in 256, 8, 16, or 32 necessarily. Nor should we just be using booleans and nulls.

Rather

this column can accept values from 10 to 30

this field can accept only numbers that are positive and not A to Z characters

this item can only accept strings with A to Z

this cell can only accept decimal values with 2 trailing positions

this column can accept true or false (sometimes YES or NO)

this column can accept "not applicable", "not entered yet", or "string"

this cell can accept "not entered yet", or numbers from 1 to 100

Simply these are "kinds of constraints" or "types of constraints".

A simple validation constraint plugin idea for a database:

  function pluginConstraint(const s: string): boolean
  begin
    result:= false;
    // check if string contains numbers, characters, whatever
    if validate(s) then result:= true;
  end;

  begin
    setupConstraint(@pluginConstraint, toSomeDatabase)
  end;

Why nulls do not help us constrain our data:

MarchZeroEight

CategoryTypingDebate