Re: Questions on possreps

On Jun 13, 1:01 pm, David BL <davi..._at_iinet.net.au> wrote:
> On Jun 13, 7:40 pm, Hugh Darwen <hughdar..._at_gmail.com> wrote:
> > 1. A selector S for type T is an operator that has certain special
> > properties that we regard as required--and I mean required in a well-
> > designed computer language, and I realise that opinions as to what
> > "well-designed" entails may differ.  The special properties are, quite
> > simply, (a) every invocation of S denotes a value of type T, and (b)
> > for every value V of type T there is an invocation of S that denotes
> > V.
>
> I'll treat that as a very concise definition of the term "selector".
> As a point of clarification I note that (a) implies that a selector
> for type T cannot also be a selector for a proper subtype of T, and
> (b) implies that a selector for type T cannot also be a selector for a
> proper supertype of T.

As to (b), either it is wrong or overly pedantic. For one, it is perfectly reasonable (and common) to define selectors with the following signature

   SubType -> SuperType

or in a "constructor" syntax

   SuperType(SubType(...))

This is no different from any other unary selector except that the single argument happens to be a SubType. Therefore, we have "trivial" supertype selectors (or "conversion operators") that serve to typecast/convert/coerce subtype values into supertype values. Finally, such selectors can be made implicit in which case the subtype selector /does/ serve as a supertype selector.

As to (a), the points above also apply to SuperType -> SubType just as well. However, depending on the type system, we define impossible conversions to result in either some "default" or "invalid" value or a type exception (type system error).

> > 3. At least one selector must be available for every type, from which
> > it follows that for every value V of every type there will be at least
> > one selector invocation that denotes V.
>
> I find this unreasonable when I consider union types such as
> PLANE_FIGURE, since it would be impractical for it to have an
> appropriate selector according to your definition (a selector for a
> subtype like CIRCLE is not deemed to be a selector for PLANE_FIGURE).

See the discussion above as it answers this issue as well. Also, I note that you have not yet defined what your notions of "supertype", "subtype", etc are. Unless you have in mind some antiquated "value based" notion of inheritance (ie the one that says "a subtype is just a subset of a types domain) then these problems never arise.

In other words, as long as there is a suitably rich set of operators (ie ad-hoc polymorphism), inheritance is irrelevant. Parametric and inclusion polymorphism serve only as devices of convenience, not of theoretical necessity.

> > 4. If a selector S is defined by a possrep declaration, then the
> > parameters for S correspond to the components of the possrep.  We
> > assume that if two invocations of S differ in at least one argument,
> > then those two invocations denote different values.  Thus, if we take
> > possrep CARTESIAN(X REAL, Y REAL) for type POINT, then the operators
> > THE_X(P POINT) and THE_Y(P POINT) are well defined: every point has
> > exactly one X value and exactly one Y value.  We assume that the
> > declaration of such a possrep guarantees that users of the type in
> > question will be able to develop whatever operators they desire for
> > that type.  (So, yes, a canonical form is needed in cases like the
> > numerator/denominator possrep for type RATIONAL.  That could be
> > addressed in the physical representation, such that
> > THE_NUM(RATIONAL(2,4)) and THE_DEN((RATIONAL(2,4)) yield 1 and 2,
> > respectively--a bit of a tall order!  It could also be addressed by a
> > constraint on the possrep.
>
> I can understand that it's important for the THE_ operators to be well
> defined, so I agree with your approach.  Another advantage is that the
> equality operator is implicitly defined.
>
> I assume the downside is that the canonical form is imposed on the
> selectors.  i.e. they may have constraints that make them harder to
> use, and this might be a source of surprise and annoyance for users,
> such as when a polar representation of a complex number fails because
> the phase wasn't in the canonical range.
>
> > Some people have argued that selectors aren't always needed--in other
> > words, they don't mind allowing a type to contain values that cannot
> > be denoted by a single expression in the language.  We admit that in
> > practice nobody would want to invoke a selector to denote the entire
> > content of the film "Gone with The Wind", a value of type Video, but
> > we still think a well-designed language should make that a theoretical
> > possibility.  I don't think we could disagree with an alternative
> > model that meets the same objectives as I have outlined above, nor
> > would we necessarily disagree with one that fails to meet them but is
> > perhaps intended for rather less general use, so long as its
> > deficiencies and advantages are clear.
>
> I agree that the aim should be that any value can be represented by a
> single expression in the language.

No, that is wrong. Any value can be represented by /at least one/ single expression. Above Hugh Darwen was discussing one particular selector S, there are arbitrarily many other selectors S1, S2, S3, ...

KHD Received on Tue Jun 14 2011 - 14:13:40 CEST