Re: Questions on possreps

From: Keith H Duggar <duggar_at_alum.mit.edu>
Date: Wed, 15 Jun 2011 07:47:49 -0700 (PDT)
Message-ID: <7fdcb431-588a-4cdc-96e1-d2fb41fa588f_at_eq2g2000vbb.googlegroups.com>


On Jun 14, 11:18 am, David BL <davi..._at_iinet.net.au> wrote:
> 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.

What potentially confuses you?

> 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 long as by your last sentence you did not mean to imply that the selector -> posrep mapping is total, fine. I find that Hugh Darwen's wording

   "A possrep declaration is a way of defining a signature     for a selector, along with a constraint ..."

is far more clear.

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

Darwen's requirement 3. makes no mention whatever of union types nor subtypes. Therefore, it is general enough to be applied to a type theory without subtypes (ex a monomorphic theory). Then you assert it is "unreasonable" when /you/ consider union types and subtypes because "a selector for a subtype like CIRCLE is not deemed to be a selector for PLANE_FIGURE". But why? You give no reason why it is unreasonable. It seemed to that you introduced unnecessarily and thereby confused yourself.

There is nothing stopping one from defining /other selectors/ for PLANE_FIGURE that take CIRCLE or whatever as arguments. In fact Darwen explicitly states that such selectors as defined above should be "[made] a theoretical possibility". In other words, a possrep defines some selector, not necessarily the most convenient selector nor even one that is physically implemented.

Of course, since Darwen requires that selectors be total, in their scheme we cannot these "selectors". Fine. let's call them "constructors" and move along.

> The rule Hugh proposed assumes every type has at least one possible
> representation, which appears to outlaw types like PLANE_FIGURE.

Why do you think requiring a representation "outlaws" types like PLANE_FIGURE? Please tell me it has nothing to do with any worry you have about /physical/ representation?

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

Why is this /theoretical/ requirement unreasonable? What evidence do you have that "dummy types" are an admmision that requiring possreps is "unreasonable" rather than simply a "no need to fill in at this time" ie place-holder convenience?

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

You failed to grasp the "what" in the irrelevant I wrote. Ie irrelevant /to what/? I thought it would be obvious that the what is /selectors and possreps as defined by D&D/. In other words /the thread topic/. Ie inheritance is irrelevant to the definition and requirements of D&D possreps. You can see that their definition is more general and able to handle, for example, monomorphic type systems.

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

I'm simply pointing out that the "just a subset of values" notion cannot even handle the simplest of mathematical constructions. For example, the standard set construction of natural numbers is not a subset of the standard set construction of integers. Likewise the standard set construction for integers is not a subset of the standard set construction of reals. Etc.

To handle even those most basic cases one must introduce the concept that a type is a set WITH an equivalence relation ie a setoid. Then a type is a set of equivalence classes, and those equivalence classes are then free to contain elements from other sets. For example, take the union of the natural number set construction and the integer set construction then define an equivalence relation making {{}} = (1,0) (ie one in both the standard natural number and integer constructions). Such setoids and/or equivalence relations are what allow one to define value based "isa" relationships for even the simplest set constructions, NOT simple the "just a subset" notion.

Once one accepts that equivalence relations are /fundamental/ to the definition of types, many of the problems you complain about become simple to solve non-problems. (BTW I am ignoring the deep ontological problems that still remain at the heart of modern foundation theories regarding unwarranted distinctions and such.)

KHD Received on Wed Jun 15 2011 - 16:47:49 CEST

Original text of this message