Path: news.cambrium.nl!textnews.cambrium.nl!feeder2.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!postnews.google.com!m10g2000yqd.googlegroups.com!not-for-mail From: Erwin Newsgroups: comp.databases.theory Subject: Re: An alternative to possreps Date: Mon, 6 Jun 2011 06:26:13 -0700 (PDT) Organization: http://groups.google.com Lines: 165 Message-ID: References: <2be6992e-4372-4adb-a9d5-1291efcfc5d6@d26g2000prn.googlegroups.com> <64afc6b2-0b6e-4872-815c-db852567ec4c@l14g2000pro.googlegroups.com> NNTP-Posting-Host: 85.234.202.89 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1307366773 11861 127.0.0.1 (6 Jun 2011 13:26:13 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 6 Jun 2011 13:26:13 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m10g2000yqd.googlegroups.com; posting-host=85.234.202.89; posting-account=-nQufgoAAABsreOCZNqo2Uyh8O-fYVPT User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLEUHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727),gzip(gfe) Xref: news.cambrium.nl On 31 mei, 11:54, David BL wrote: > > > Is there anything in TTM that prohibits one from making every type a > dummy type? =A0Would 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? =A0If so would it be t= rue > > > to say it seems to overlap in purpose with CONSTRAINT declarations? > > > Preconditions such as "the argument value for any LN(FLOAT) invocation > > must be >=3D0" ? > > Yes. =A0Eiffel uses that term. I think "domain" would be a more > conventional term, but the database community has often used 'domain' > for 'type'. =A0I 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 ! =A0Eve= n > > without type inheritance, it is not impossible to define a (distinct) > > type STRICTLYPOSITIVEFLOAT. =A0If 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 "non- selector" 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? =A0E.g. foo(x,y) is defined on x+y > 0. =A0Is 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)<=3D0 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? =A0Can 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. =A0No distinctions between built-in > > and user-defined types. > > I would say it may be impractical if the answers to Q5 are no. =A0The > 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. =A0This 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 : - if you set up the super/subtype relationship without using a UNION type, then declaring RATIONAL requires the existence of INTEGER (otherwise RATIONAL's possrep cannot be defined), and INTEGER requires the existence of type RATIONAL (_and_ the existence of operators for RATIONAL, otherwise the type constraint for INTEGER in terms of RATIONAL cannot be defined, but that type constraint will have to involve INTEGER factoring, which requires the existence of type INTEGER, etc. etc.) - if you set up the super/subtype relationship by declaring an extra type NONINTEGERRATIONAL (with a constraint that numerator is not a perfect multiple of denominator), and then declare RATIONAL to be a UNION type of INTEGER and NONINTEGERRATIONAL, then you'd still be in trouble once you start defining operators such as rational division, which is not the same operator as integer division, while the IM prescriptions requires, essentially, that operators such as, e.g. "DIVIDE(RATIONAL,RATIONAL)" and "DIVIDE(INT,INT)", are effectively the very same operator if INT is effectively a subtype of RATIONAL. > From an implementation perspective I cannot see a good reason to > outlaw adding supertypes to pre-existing types. =A0E.g. it is easy to > emulate in C++ Are they "outlawed" ? Did I say that in those words ?