Re: Questions on possreps

From: Keith H Duggar <duggar_at_alum.mit.edu>
Date: Thu, 16 Jun 2011 06:26:42 -0700 (PDT)
Message-ID: <9b85d930-21c7-4ed0-88d4-548babc47941_at_y7g2000prk.googlegroups.com>


On Jun 16, 5:26 am, David BL <davi..._at_iinet.net.au> wrote:
> On Jun 15, 10:47 pm, Keith H Duggar <dug..._at_alum.mit.edu> wrote:
> > 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?
>
> Many things.
>
> I wasn't sure why you stated (b) is wrong or overly pedantic.  More
> specifically, I wondered whether you hadn't appreciated the objective
> behind the D&D definition, or perhaps you had but didn't see a reason
> to be concerned with the concept of possible representations.

The latter. I didn't see any reason for practical concern because there would be a multitude of more convenient operators to choose/ construct/select/express the values we want.

That said, in precise terms you are correct that D&D requirement 3) would not allow any operators that were not surjective on the domain of T to be deemed "selectors" for type T. I'm not sure why this is important for them to requirement. For example, what if selectors were allowed to be partial, and a instead possreps were required to defined /surjective/ selectors?

What do we gain by requiring selectors to be surjective? I suppose it serves as an simple demarcation between selectors and arbitrary operators of type T <- ... .

> > > 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.
>
> I think I understand. Can I ask that we stay with the D&D
> terminology?  I see no need for another term "constructor" -
> we can use "selector" for the narrow case and "operator"
> for the more general case.

Ok.

> So to summarise what I believe you are saying: Although
> requirement 3. requires a verbose selector to be defined on
> PLANE_FIGURE, it is not expected that it will ever be invoked
> within a literal in practise because there can be many other
> far more convenient operators.

Exactly, that is my understanding. As you have correctly pointed out, in D&D terminology operators that do not meet requirement 3 cannot be called "selectors". In my opinion this is not of any pratical importance.

> > > 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?
>
> At the moment the only issue seems to be with the need to define a
> verbose selector, that no-one intends to actually use. So "outlaw" is
> not the right term to use.
>
> > > 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?
>
> Ok, I could easily be wrong. I won't comment further on that
> since I haven't studied the relevant parts of the TTM book.

Maybe we will get lucky and Hugh Darwen might respond to this particular question here ;-)

But, what exactly would you consider unreasonable? A requirement to explicitly define the structure of at least one possrep? (Rather than leaving it as undefined/dummy.)

> > 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.)
>
> Do you see this as having some direct impact on the design of a
> practical DDL?

Yes, I believe a setoid perspective (or some perspective that includes equivalence relations) does guide and impact the design of a practical DDL. I'll try to give some examples when I have more time than now.

Thanks!

KHD Received on Thu Jun 16 2011 - 15:26:42 CEST

Original text of this message