Re: An alternative to possreps

From: Bob Badour <bob_at_badour.net>
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

Original text of this message