Re: An alternative to possreps

From: Erwin <e.smout_at_myonline.be>
Date: Sat, 11 Jun 2011 15:38:24 -0700 (PDT)
Message-ID: <d996e9a3-df8c-44aa-8fa3-70ac9531ecf4_at_c41g2000yqm.googlegroups.com>


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."

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.

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. Received on Sun Jun 12 2011 - 00:38:24 CEST

Original text of this message