Re: An alternative to possreps
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".
> 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.)
> 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 ?
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