Re: Questions on possreps

On May 29, 8:12 am, Erwin <e.sm..._at_myonline.be> wrote:
> Haven't gone through the other responses first, perhaps I should have,
> but anyway here goes (see inlined answers) :
>
> On 26 mei, 06:04, David BL <davi..._at_iinet.net.au> wrote:
>
> > 3) Is it correct that a POSSREP typically doesn't unambiguously define
> > a method for encoding values of type T on some physical medium?
>
> The POSSREPs as defined in the TTM literature have nothing to do with
> physical encoding.
>
> > 4) Consider a POINT value is encoded in computer memory using a '\0'
> > terminated ASCII string such as "(1.34,-6.2)", and must be parsed
> > according to some well defined grammar in order to retrieve the x,y
> > coordinates. Does this qualify as a CARTESIAN representation?
>
> It could qualify as a valid POSSREP for the POINT type, but it is a
> different one from the CARTESIAN possrep typically used in
> Date&Darwen's relational writings.

What do you mean it could qualify as a valid POSSREP for POINT when you just stated POSSREPS have nothing to do with physical encoding?

> > 5) Is it correct to say that in Tutorial D types are sometimes defined
> > in terms of possreps?
>
> Yes. In fact this holds for all of them, except then the "basic" ones
> such as INTEGER, BOOLEAN, ...

Would you say union types are defined in terms of POSSREPS?

> > 13) Is it appropriate for assumptions about types employed in POSSREP
> > declarations to be visible in the signatures of the operators at the
> > logical level of discourse? For example, that the return type of
> > THE_X is RATIONAL:
>
> > OPERATOR THE_X ( P POINT ) RETURNS RATIONAL;
>
> Don't see a problem. This operator coming into existence is a direct
> consequence of the fact that POINT is declared to have an X component
> of type RATIONAL in one of its declared possreps. So it's a direct
> consequence of the type definition, which is itself also at the
> logical level of discourse, no ?

I agree there is no problem assuming a POSSREP is at the logical level of discourse. However, I would use REAL not RATIONAL.

> > 17) Why are only some operators called "selectors"? I would have
> > thought this distinction only arises from physical implementation
> > concerns. Is it not true that at an abstract level any operator that
> > returns values of type T can be regarded as a means of selecting
> > values of type T?
>
> You're right. The term was probably introduced to be able to speak of
> "operators" in general, instead of having to continuously say
> "operators and/or literals". Just like OO texts might want to talk of
> "methods" in general, rather than "methods and/or constructors".
>
> (Note that literals and selectors are not the same thing. All
> literals are selectors, but not all value selectors are literals.
> Literals are value selectors with no arguments, while there might be
> other value selectors that do take arguments. But the term "value
> selector" is restricted to those cases where the arguments match the
> POSSREP declaration :
>
> VAR RATIONAL X,Y;
> VAR POINT P = CARTESIAN(X,Y); /* this is a value selector but not a
> literal */
> P = SHIFTHORZ(P, 2); /* allthough SHIFTHORZ returns a POINT value,
> and must thus itself _contain_ a POINT value selector, SHITHORZ itself
> is not a "value selector" */

I would define a literal to be any expression (of nested operator invocations) containing no variables.

On page 117 Of Into, Date states:

"selector invocations - are a generalisation of the more familiar concept of a literal (all literals are selector invocations, but not all selector invocations are literals; in fact, a selector invocation is a literal if and only if all its arguments are literals in turn)". Received on Mon May 30 2011 - 05:04:02 CEST