Re: Questions on possreps

From: David BL <davidbl_at_iinet.net.au>
Date: Tue, 14 Jun 2011 08:18:08 -0700 (PDT)
Message-ID: <fb696fc4-1c05-4dbd-84b2-2a8b75e411a7_at_d19g2000prh.googlegroups.com>


On Jun 14, 8:13 pm, Keith H Duggar <dug..._at_alum.mit.edu> wrote:
> 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.

I agree with you in the sense that any operator satisfying (a) but not necessarily (b) can be regarded as a (type safe) means for selecting values of type T. I do regard this as a potential source of confusion.

D&D want to formalise the concept of "possible representations". This explains their definition of "selector". Indeed there is one selector for each possible representation.

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

I have D&D's inheritance model in mind. In what sense are you blaming something on inheritance?

The rule Hugh proposed assumes every type has at least one possible representation, which appears to outlaw types like PLANE_FIGURE. I assume Hugh would see this as justifiable in the version of TTM without an inheritance model. However I note that in principle there is nothing to stop one from defining a POSSREP of PLANE_FIGURE that works in the manner of a discriminated union (i.e. with a 'tag' component that indicates which one of a finite number of kinds of figures is represented, and the other components are used in some adhoc manner for things like the radius of a circle, perhaps using zeros when they are inapplicable to satisfy the canonical form requirement). This is obviously ugly and impractical - leading to a verbose selector for example. It follows therefore that D&D would see that the IM is an important extension to the basic TTM.

As I see it, irrespective of whether one has some notion of inheritance in mind, the simple truth is that it is unreasonable to require every type to have a POSSREP and I'm sure D&D agree with that (that's why in TTM plus IM they have "dummy types" which are union types without any POSSREP of their own).

I see nothing illogical with D&D's approach. However it doesn't appear to be the simplest possible approach. I see nothing at all wrong with their IM. On the contrary it is excellent. I see no reason for pejorative terms like "antiquated".

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

If one of the ways to help achieve a rich set of operators is to utilise inheritance as a device of convenience, would you then say inheritance helps to make itself irrelevant?

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

I think there is an ambiguity in what 'single' was intended to mean. I thought when Hugh said 'single' he instead meant that a single expression was able to denote a value (rather than multiple expressions somehow all being required to represent the value, even a very complicated one). Received on Tue Jun 14 2011 - 17:18:08 CEST

Original text of this message