Page 1 of 1

TYPE inheritance implications

Posted: Tue Jul 30, 2013 3:33 pm
by Chris Walton
Given a type definition
TYPE A POSSREP { VALUE CHAR } ;
which generates the following operators
A ( CHARACTER ) RETURNS A
IS_A ( A ) RETURNS BOOLEAN
THE_VALUE ( A ) RETURNS CHARACTER
TREAT_AS_A ( A ) RETURNS A

and the type definition
TYPE B IS { A CONSTRAINT ( TRUE ) POSSREP { VALUE = THE_VALUE ( A ) } } ;
then for B only the following operators are generated
IS_B ( A ) RETURNS BOOLEAN
TREAT_AS_B ( A ) RETURNS B

Why is TREAT_AS_B ( A ) legitimate, as I see no way to treat an unconstrained value as a constrained one? I would have anticipated that rather than "down-casting", the type inheritance would have permitted "up-casting" (in other words, TREAT_AS_A ( B ) RETURNS A would be legitimate whereas TREAT_AS_B ( A ) RETURNS B would not).

Re: TYPE inheritance implications

Posted: Wed Jul 31, 2013 10:36 am
by Dave
TREAT_AS_B ( A ) RETURNS B essentially "falls out" automatically from the type definition mechanisms, without any assurance that it's actually meaningful. At a glance, your criticism and suggestion (by way of what you would have anticipated) sound valid to me, but I'm inclined to let Hugh Darwen comment on this before I make any changes. If he doesn't see it in a day or two, I'll point him to this thread.

Re: TYPE inheritance implications

Posted: Mon Jan 29, 2018 6:08 pm
by spencer
Hello,

BTW thank you for all of the hard work to make this project happen. It has taken me too long to "get into" this project and give it the attention it deserves. Maybe all of this has already been resolved, but I did run into a few issues with Rel this morning regarding this very question.

Anyway, I was wondering exactly what is being said by the following:

TYPE A POSSREP { I INTEGER }

Ok, we have a type, a named set of values, called A, whose possible representation consists of an integer component called I.

TYPE B IS { A CONSTRAINT (TRUE) POSSREP { I = THE_I ( A ) } }

Ok, another type called B, which is an A, and the constraint that ALL B values are A values. The constraint that defines B values is just TRUE. It does beg the question, keeping with some of the "newer" discussions surrounding type and inheritance, what exactly the "NOT" specification would look like? The NOT specification being an example of a A value that is not a B value. (I mean "newer" here having just watched the Chris' O'Reilly seminars on type and inheritance).

Taking a general view, A denotes a set of values, and A is a subtype of itself, but not a proper one. Likewise, B is a named set of values, and B is a subset of itself, but not a proper one. In fact, unless I am misleading myself, B can never be a proper subset of A. That is, there are no values "that are just A values" that aren't also B values. The model as outlined in TTM does have constructs that support these ideas, that of UNION and DUMMY types.

Type T shall be a UNION type iff it is a scalar type and there exists no value that is of type T and not of some immediate subtype of T.

A type shall be a DUMMY type iff either of the following are true:

1) It is one of the types alpha and omega
2) It is a UNION type, has no declared possible representation (and hence no selector), and no regular supertype.

And to elaborate: A type shall be a regular type iff it is a scalar type and not a DUMMY type.

It does appear that our type hierarchy, types A and B in the example above, that type A is a scalar type, and there exists no value of type A that is not of some immediate subtype of A, namely B, A has a declared possible representation, and is not alpha or omega, hence A is NOT a DUMMY type. Therefore, A is a UNION type. Accordingly, it's my understanding that UNION types must be explicitly declared as such. I am not sure that even if we changed the delcaration for type A to

TYPE A UNION POSSREP ( I INTEGER )

would fix the issue at hand. In fact, a variable of declared type A will always have a most specific type of some proper subtype of A, namely B. However, B is not a proper subtype of A. That is, all B values are A values. I believe that a UNION type must have a least two immediate subtypes, because there is only one subtype in our example. In fact given the CONSTRAINT specification, there can only ever be one subtype, namely B.

What to make of all this? Well, I believe that in our example above A and B are in fact the same type, as in they denote specifically the same set of values.

Thoughts? Still learning all of this stuff.

Re: TYPE inheritance implications

Posted: Mon Jan 29, 2018 6:42 pm
by Dave
I know what Rel will do with the definitions of A and B, but how they should be considered within the TTM model I'm not sure I can answer.

Hopefully, Hugh will see this and can answer.

Alternatively, as this is more of a TTM question than a Rel question, perhaps it's worth asking on the email-based TTM discussion group linked at the bottom of http://thethirdmanifesto.com/

Re: TYPE inheritance implications

Posted: Mon Jan 29, 2018 7:02 pm
by spencer
Hello,

I do not see a link to a forum at the bottom of that website. I used to have Hugh Darwen's email address, but alas, that was many moons ago.

And, you are a rock star, and your hard work appreciated. I have been using Rel for a few days now, and cannot wait to use this in some production application in the future. Need to re-wrap my head around the fundamentals again!

Cheers,
Spencer

Re: TYPE inheritance implications

Posted: Mon Jan 29, 2018 7:03 pm
by spencer
Bah, I see the links now.

Re: TYPE inheritance implications

Posted: Tue Jan 30, 2018 12:59 pm
by HughDarwen
This is really an issue with our inheritance model (IM) and thus only indirectly an issue with TTM (because TTM says that if inheritance is supported, then it must be via our IM).

Spencer's example contravenes the IM precisely because B is not a proper subtype of A (see IM Prescription 5a). Thus CONSTRAINT(TRUE) violates the IM. You might argue that for that reason Rel should raise an error, but I wouldn't expect it to do so because it can hardly be expected to be able to detect every constraint that is a tautology. I suppose there would be no objection to detecting "easy" cases like CONSTRAINT(TRUE) but personally I have never been in favour of such practice.

Hugh