Re: An alternative to possreps

From: Erwin <e.smout_at_myonline.be>
Date: Mon, 6 Jun 2011 06:26:13 -0700 (PDT)
Message-ID: <c25a65f4-c3e4-4dc0-a6ef-c851c6278d20_at_m10g2000yqd.googlegroups.com>


On 31 mei, 11:54, David BL <davi..._at_iinet.net.au> wrote:
>
>
> Is there anything in TTM that prohibits one from making every type a
> dummy type?  Would that make it essentially the same approach which
> I've described?

Not "in TTM". What prohibits this is "reality", I'd rather say.

If you're interested in a subset of T, then you can't define this subset by means of UNIONs involving T.

And if you're interested in UNIONing things together because that union somehow is of interest to you, then you still must be given some things to union. Somewhere down the line, some non-dummy types must be just given.

I didn't look at the details of your proposed approach because you said yourself that it is neither more nor less powerful than TTM possreps.

> > > 4. Can preconditions be declared on operators?  If so would it be true
> > > to say it seems to overlap in purpose with CONSTRAINT declarations?
>
> > Preconditions such as "the argument value for any LN(FLOAT) invocation
> > must be >=0" ?
>
> Yes.  Eiffel uses that term. I think "domain" would be a more
> conventional term, but the database community has often used 'domain'
> for 'type'.  I would treat ln(0) as undefined.
>
> > D&D's position here can be summarized, I think, as "this issue must be
> > addressed by defining the proper type".
>
> > (And note that this approach does not require type inheritance !  Even
> > without type inheritance, it is not impossible to define a (distinct)
> > type STRICTLYPOSITIVEFLOAT.  If you can _prove_ to them that this
> > approach is unacceptably impractical, please please do !)
>
> I agree it seems impractical, and selectors are treated differently to
> other operators (only selectors have constraints).

Not quite accurate. Selectors do not "have constraints". Possreps do. As a consequence, of course whenever a selector invocation is made, the arguments given must satisfy that constraint, or an exception results. But I don't see how this is different from "nonselector"  operators such as LN(FLOAT) ! There too, the arguments effectively passed must satisfy a certain predicate. I find it only a psychological difference that in the case of selectors, the arguments' predicate is declared as part of the construct that gave rise to the existence of the selector operator, whereas in the case of "regular" operators, that predicate is declared in the documentation, or in the metadata, or in the worst case, it is merely implied by the operator's implementing code.

> Also, what happens with non-separable constraints on operators with
> multiple arguments?  E.g. foo(x,y) is defined on x+y > 0.  Is one
> forced to make it into a unary operator on a type which can express
> that constraint on its POSSREP?

No, one is not forced to do that.

OPERATOR FOO(X INT, Y INT) RETURNS ... ; IF (X+Y)<=0 RAISE ILLEGALARGUMENTEXCEPTION("...");   /* note that dealing with exceptions, or how to raise them, is not part of TTM */
...
END OPERATOR;
> > > 5. Can additional POSSREPS be added to a type without modifying the
> > > original declaration of that type?  Can a new supertype be added to
> > > the type system without needing to modify the definitions of all its
> > > subtypes?
>
> > No and No.
>
> > As for the first "No" : I don't see an impractical difference between
> > "just adding an extra possrep", and "re-issuing the entire type
> > declaration which now includes the extra possrep".
>
> > As for the second "No" here, this has been discussed on TTM and nobody
> > changed positions.
>
> A type system could be so large that these restrictions create
> difficulties.

Completely agreed. But **Tutorial** D is for tutoring purposes exclusively.

I've made this mistake dozens of times myself : so beware that you

DON'T take certain "properties" of the **Tutorial** D language, to be
prescribed properties of the Manifesto **per se**.  Other D languages
can be totally different from **Tutorial** D, and still be a D (all
THAT takes is to conform to the RM (+IM) prescriptions+proscriptions PER SE). (I probably even made this mistake once again where I said that "declaring a UNION type requires re-declaration of the constituent subtypes". This is so in Tutorial D. But I don't think there is an explicit prescription to this effect in the manifesto per se. Mea culpa.)

Hence, the freedoms an implementer has to _deviate_ from **Tutorial** D, really go quite far.

> > > 8. Is it possible to add super-types to the built-in types?
>
> > All types are first-class citizens.  No distinctions between built-in
> > and user-defined types.
>
> I would say it may be impractical if the answers to Q5 are no.  The
> built-in types are probably analogous to a third party library which
> users have no control over.
>
> For example, if the system provides a built-in type INTEGER but not
> RATIONAL, then when someone implements the latter in terms of a pair
> of INTEGER they also want to declare RATIONAL to be a supertype of
> INTEGER, so that integers can be passed into all their operators that
> take RATIONAL.  This is awkward if they have to edit the system
> provided definition of INTEGER.

In the most recent book, "Database Explorations", Date argues that integer numbers are not rational numbers. You should not take the existence of a certain kind of correspondance between the _algebraic structures_ "Z,+,*" and "Q,+,*" (the former is a 'subgroup' of the latter, it is said) to imply that "the members of Z must be a subset of the members of Q".

At any rate, the whole idea is also problematic in that :

> From an implementation perspective I cannot see a good reason to
> outlaw adding supertypes to pre-existing types.  E.g. it is easy to
> emulate in C++

Are they "outlawed" ? Did I say that in those words ? Received on Mon Jun 06 2011 - 15:26:13 CEST

Original text of this message