Re: Questions on possreps

On 30 mei, 05:04, David BL <davi..._at_iinet.net.au> wrote:
> 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?

Sorry. Missed the "suppose ... is encoded in memory as a nulterminated  string".

I meant to say that there is nothing in the concept you describe that would make it an "invalid" (logical) possrep. In fact, ALL types can "conceptually" be regarded as having a "STRING" possrep, which produces the "externalization" of any value of the type. More or less equivalent to Java's toString() method that exists for all objects.

However, in its role as a "physical possrep", there is more to it than what you say. It is not sufficient to say "encoded as a nulterminated  string" to determine the actual bit pattern for a value. Because the encoding of the string itself is also relevant, and a possible source of differences. UTF-8 gives different bit patterns compared to UTF-16. Byte ordering conventions produce different bit patterns for any kind of integer numbers (except the single-byte ones of course). etc. etc. Switching the order of the X and Y components in an encoding that is based on the (two-component) CARTESIAN possrep, will produce different bit patterns too.

That was my point where I said "targeted to the machine" : specifying a physical possrep requires the specification of _every single detail_ that plays a role in determining the ultimate bit pattern. So for this reason, your CARTESIAN possrep does not qualify as a valid physical possrep, because it is incomplete.

> > > 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?

Oops. You're probably right. I wasn't thinking of those. UNION types typically even will not have a POSSREP of their own (allthough it is always possible to conceive a toString()-like POSSREP which includes both "actual" typename and externalization-of-value. But beware that in the Manifesto, declaring a UNION type is _not_ merely a matter of saying :

TYPE PLANE_FIGURE IS ELLIPSE UNION POLYGON; /* where ELLIPSE and POLYGON were formerly root types */

Strictly speaking, the Manifesto requires that "simultaneously", the declaration of the existing root types is changed to

TYPE ELLIPSE IS PLANE_FIGURE ... , TYPE POLYGON IS PLANE_FIGURE ... ; /* note the comma, as opposed to a semicolon */

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

I try to comment as little as possible on the REAL vs. RATIONAL stuff.

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

Well then you got it. That's how D&D define them too. I was too restrictive where I said "selectors with no arguments", which is in fact even nonsensical. Received on Mon May 30 2011 - 11:09:10 CEST