Re: Questions on possreps

On Jun 13, 6:01 pm, David BL <davi..._at_iinet.net.au> 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.

I deliberately omitted any reference to the IM. It seems from your response and Keith Duggar's that there is more interest in the IM in particular than in the general type model into which the IM is supposed to be incorporated. As Erwin has already noted, the IM makes certain modifications to the base model.

Anyway, to address this observation for now (I might come back to other points at a later date):

Your points are correct but nevertheless if T2 is a subtype of T1, then an invocation of a selector for T1 can denote a value of type T2. It wouldn't be a selector for T1 if that were not the case. Similarly, every invocation of a selector for T2 denotes a value of type T1. Thus the problem that selectors are intended to solve remains solved.

I should perhaps make it clear that although Tutorial D includes explicit syntax for defining types via possrep declarations, TTM itself does not prescribe syntax. A type that is defined solely in terms of operator signatures conforms to our model if those operators include at least one that satisfies the requirements for being a selector (pace the IM as already noted) and counterparts of our THE_ operators that in Tutorial D are implicitly spawned by possrep definitions. A language that somehow enforces these requirements on every type definition (pace the IM) conforms to our model.

Hugh Darwen Received on Tue Jun 14 2011 - 19:39:52 CEST