Re: Questions on possreps

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.

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

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.

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

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

Ok

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

Do you see this as having some direct impact on the design of a practical DDL? Received on Thu Jun 16 2011 - 11:26:53 CEST