Re: An alternative to possreps

From: Erwin <e.smout_at_myonline.be>
Date: Wed, 8 Jun 2011 03:01:12 -0700 (PDT)
Message-ID: <7c1e0265-a57d-4b44-a644-95c673903b58_at_z37g2000yqb.googlegroups.com>


On 7 jun, 10:05, David BL <davi..._at_iinet.net.au> wrote:
>
> Yes, but that is not a problem.  Let Ellipse be a "dummy type".  If
> you're interested in a subtype Circle of Ellipse then you can simply
> declare Circle as another dummy type. I'm assuming you can declare
> subtype relationships between dummy types.  In my approach you use
> these declarations:
>
>     type Ellipse;
>     type Circle;
>     Circle isa Ellipse;
>
> I consider types like Circle and Ellipse to be defined by their
> operators.  In that sense there is no problem treating all types as
> "dummy types".

In TTM, and more precisely in the inheritance model, the term "dummy type" is quite precisely defined. A type is a dummy type if and only if it is defined as being a UNION type that has no possrep of its own. The term is relevant only within the context of the inheritance model. And even then, it could be questioned just how relevant, because it still remains the case that "all types are first-class citizens".

You seem to be confused in the area of "manifesto-with-inheritance" (M +I) vs. "manifesto-without-inheritance" (M-I). In M-I, there is no speaking of dummy types because there is no I. Yet, there must still be a way to let the user define types.

Now, your argument seems to be that between the following two, (b) is better for some reason :

(a) stating the definition of a type in terms of what its constituent components are, and deriving from that which "constructors" (/ selectors) will exist, including which preconditions (/constraints/ predicates) apply to the values of the arguments passed onto such "constructors",
(b) not stating the type per se, but instead stating what "constructors" exist (including preconditions etc.), and deriving from that that the type exists.

I see no difference. Except that (b) gives me the feeling that if I were a user using those types/operators, it might be harder for me to discover which types/operators are available to me. Just a feeling.

Furthermore, if types are to be defined in terms of their

"constructors", then you cannot carry over that MO to what TTM calls
"dummy types", because those types simply _do not have_ a
"constructor" (one of their own, I mean).  So just like TTM, you need
to introduce a second way for defining types, which is, exactly as in TTM, by declaring the UNION that makes up the type.

> That might be true in D&D, but I see no reason for that in principle.
> Operators are sufficient for allowing (logical) representations of
> values (using nested expressions of operator invocations).  E.g. the
> operator
>
>     Circle <--- circle(Point centre, Real radius) on radius >= 0;
>
> allows for circle values to be (logically) represented without any
> POSSREP.
Does it ? I see here that a circle has a Point component called 'centre', that it has a Real component called 'radius', and that the value of the 'radius' component is subject to a certain constraint. How is that different from what a possrep achieves ? I say the possrep is still there, even if there is no keyword 'POSSREP' in the syntax. (Note that if your complaints are about the _syntax_, then by definition you are only criticising the Tutorial D language, not the manifesto itself.)

(To pursue that latter remark a bit further : D&D also insist that 'relational assignment' must be supported in order to comply with the manifesto. In my project SIRA_PRISE, I "don't do that", so to speak. I don't allow the user to use the ' := ' token in between a relational variable on the LHS and a relational expression on the RHS. Yet, D&D still agree that I do comply with the manifesto, because I do offer Insert+delete+multiple assignment, which is perfectly equivalent to "assignment as such".)

> You appear to be contradicting yourself in saying both:
>
> (a) "this issue must be addressed by defining the proper type"; and
>
> (b) the arguments to LS(FLOAT) must satisfy a certain predicate.

(a) was an _assumption_ of mine of what D&D's answer would probably be if your questions/objections/remarks were put to them directly. It is a valid solution to the problem, but I agree it might not be the most practical one in every circumstance. BTW, it is not forbidden to join the TTM discussion list and throw your questions/proposals in there.

Regardless : the "business rule" that the argument to an LN() invocation must be strictly positive, still applies no matter what.

Do you think the difference is more than merely psychological whether that rule is stated as a "precondition" in an operator definition, as a "possrep constraint" in a type definition for POSITIVEREAL, or (to a lesser extent) just documented as a few lines of open-source code that raise the IllegalArgumentException if and when needed ?

> These problems don't exist in the approach I outlined.  E.g. assuming
> Integer is already defined, one can define Rational like this:
>
>     type Rational;
>     Integer isa Rational;
>     Rational <--- rational(Integer n, Integer n) on d != 0;
>     Rational <--- divide(Rational q, Rational d) on d != 0;
>     etc

Which rationals are integers and which aren't ?

In TTM, the system can know because the system is given the type constraint that answers precisely that question, as a part of the type declaration (mind you, always supposing it were possible to begin with to have the integers as a subtype of the rationals).

How does the system know this in your approach ? Is there a separate operator to be declared and implemented called 'isInteger(Rational x)' ? Received on Wed Jun 08 2011 - 12:01:12 CEST

Original text of this message