Re: An alternative to possreps
Date: Sat, 11 Jun 2011 17:48:45 -0700
Message-ID: <irmdnQSjr_ltkWnQnZ2dnUVZ5hydnZ2d_at_giganews.com>
Erwin wrote:
> On 11 jun, 22:32, Bob Badour <b..._at_badour.net> wrote:
>
>>Erwin wrote: >> >>>On 9 jun, 11:49, David BL <davi..._at_iinet.net.au> wrote: >> >>>>Assuming Tutorial D doesn't balk at recursive types, >> >>>It does. >> >>Does it? It doesn't have to proscribe recursive types outside of base >>relations. If it does proscribe them in derived relations, I think >>that's a flaw.
>
> Not only does Tutorial D do so, even the Manifesto per se does so :
>
> (from pg. 142-144) "It is an open question as to whether any scalar
> type T can have a possrep that is defined, directly or indirectly, in
> terms of T itself. [...] Thus, the open question is whether
> recursively defined scalar types should be permitted. We do not feel
> obliged to legislate on this question [...] , for the purposes of the
> present book however, we follow the principle of cautious design and
> assume they are not permitted."
So, they don't proscribe it. They are merely cautious.
> But note that the discussion here concerns strictly scalar types, and
> that David's example is, imo, more in the realm of nonscalar types,
> seeing as it concerned set values.
>
> As it has been pointed out on the discussion list (_well after_ the
> book was published, of course), recursion need not be a problem if you
> can safely assume there will be some point where the recursion ends,
> and there will thus be no infinite regress. Empty relation values are
> an "end point" in "recursive relation types". A second possrep might
> be an "end point" in writing value selectors for a scalar type T, if
> some possrep of that type includes a component of type T (if there is
> no such second possrep, then there is necessarily infinite regress in
> specifying a value selector, and that case is unacceptable).
>
>
>
>
>>>Furthermore, the concept of wanting to fit graph structures in a >>>scalar type definition seems inappropriate. I'm inclined to suggest >>>that your "proliferation of types" derives from this (inappropriate) >>>desire (to make graphs fit with the scalar types feature) (or at least >>>to make them fit in a way that is really inappropriate - see further). >> >>>The canonical way for dealing with trees (and in fact arbitrary >>>graphs), is to observe that they are a set of nodes plus a set of >>>edges. So a "graph" type is a type that has two components : NODES >>>and EDGES. This means that a graph type can be considered as being a >>>TUPLE type with two attributes, or it can be considered as being a >>>scalar type with two components NODES and EDGES. The difference >>>between these two options is in fact negligible. >> >>>But the important thing to observe is that both NODES and EDGES will >>>be set-valued in either case, and in the RM context that means : they >>>will be relation-valued components (or tuple attributes). From that >>>point onward, you are outside the realms of what scalar types and >>>possreps give you, instead you've passed over into the realm of >>>operators of the relational algebra (plus transitive closure and its >>>generalized version). >> >>No, that's still inside the realm of possreps. I see no legitimate >>reason to limit the operations on values. If a value is a relation, it >>only makes sense to operate on it with relational operations.
>
> I don't think I was "limiting the operations on values". I merely
> intended to point out that from the point on where any THE_operator
> yields a relation value (THE_EDGES), you no longer have any operators
> available (for operating on that relation value) _that derive from a
> scalar possrep declaration_. There's no way for "extracting component
> values" from relation values. Computing with relation values requires
> the given operators that are designed for that purpose.
I think you are missing the point that those are exactly the operators that derive from a scalar possrep declaration of a relation value and hence the operators are available.
> That's exactly what you said, too, so I don't think we disagree. But
> perhaps my verbiage creates more confusion than it solves. If that is
> so, I'll just have to observe that it's too difficult to be precise,
> and just have to stop.
Fair enough. Received on Sun Jun 12 2011 - 02:48:45 CEST