Specialization By Constraint

In the type system defined by Date and Darwen in TheThirdManifesto, types are rigorously defined as sets of values, and subtypes are subsets of values. The subsets are defined by constraints on the values that can belong to them. So if type B is a subtype of type A, then there is a constraint predicate that defines which values of type A are also values of type B. B is a specialization (subtype) of A, defined by the constraint.

Theirs is a much more rigorous definition of 'type' than one typically finds in the OO world.

Exemplary usage (from ChrisDate at Database Debunkings http://www.dbdebunk.com/x_type_inher.htm ):

: "First, Hugh Darwen and I have never claimed that our brand of type inheritance would be useful "in an OOPL." Au contraire, in fact: We recognize that our brand of inheritance doesn�t work with objects (at least inasmuch as one can agree on what "objects" are). To be specific, if using "an OOPL" means using objects that have object IDs, then we recognize that specialization by constraint (S by C) and generalization by constraint (G by C) -- see my response to KU earlier -- can�t be made to work. Since we regard S by C and G by C as essential components of a good model of subtyping and inheritance, we conclude that "OOPLs" (or objects) and a good model of subtyping and inheritance are incompatible concepts. This is one of several reasons why we reject objects, as such, entirely in TheThirdManifesto."

The link above doesn't work.. here is an archive:

http://web.archive.org/web/20021105194148/www.pgro.uk7.net/x_type_inher.htm

Also what's the deal with these men on dbdebunk using microsoft word and a microsoft webserver to publish their articles anyway? Don't they use a database to manage their data? Or is it too hard to use a database in the real world? Also, their date formats are lies. Their main website is flooded with 04/03/04 style dates and even ones like 03/04 which are completely meaningless in a proper database - in fact even in a proper publication nonetheless a database. They don't eat their own dogfood, they don't practice what they preach.. and they need to learn how to program.' On the other hand, I do take their matters seriously and agree with their philosophies even if they are imperfect in too many senses.

Some idle musings...

Date and Darwen's teaching language, TutorialDee, is StaticallyTyped and StronglyTyped. I've often wondered what a language would look like if constraints applied only to name bindings (variables and pseudo-variables such as parameters and return types), with no explicit subtyping or or inheritance. You would have a form of DynamicTyping, in which it makes no sense to define inheritance. In essence, ThereAreNoTypes, and constraints would be checked at run time whenever a binding is initialized (variable initialization, assignment, argument passing, etc.). I suspect that this would be a very fluid environment for programming, but it would be difficult to have efficient execution. (On the other hand, the automatic constraint checks might eliminate a lot of code that otherwise would be written to do such checks explicitly.)

An extremely clever compiler might be able to recognize cases where the constraint predicate of a source guarantees a priori that a target's constraint predicate would be met, and could elide the check -- effectively, the compiler/interpreter would discover and exploit implicit subtype relationships.

I suspect that explicit type names would still be wanted as shorthand for repeatedly-used constraints, especially for defining aggregate types (records, tuples, arrays, etc.). Although, considering that a constraint is simply a predicate, one could encapsulate a constraint as a boolean-valued function. Interestingly, D&D's only aggregate types are tuples and relations, and they explicitly avoid introducing type names for these. (Although they don't rule the possibility out -- they simply didn't want to address the question of whether two different type names with similar definitions are the same.) -- DanMuller, mulling things over

Many languages, such as PascalLanguage, have had SpecializationByConstraint (think the subrange type) for quite a while; though most limit it to things like specifying subsets of the integers, rather than a general means of subtyping objects.

One thing that bothers me is that NiklausWirth took away this constraint in later versions (Oberon, ComponentPascal). Also, an enumeration is a constraint similar to a range. Sets are similar constraints. As are fixed arrays a constraint. All these available in modern pascals such as FreePascal/DelphiLanguage and most likely Ada.

      type 
        Tenum = (val1, val2, whatever);  //where val1 is zero by default
      type
        Trange = 0..50;
      type
        Tsomeset = set of enum;
      type
        Tarray3 = array [0..2] of integer;

See DateAndDarwensTypeSystem