 | |
#21
 
| |||
| |||
|
Re: Questions on possreps -
06-15-2011
, 01:50 AM
|
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. |
between our approaches.
Consider this example of two operators used to allow any natural
number to be represented (where I'm assuming that the number 0 is a
natural number, but not to be confused with the nullary operator 0
that denotes that number, and s is the successor operator):
Natural <--- 0;
Natural <--- s(Natural);
I note that under TTM, s is not a selector for type Natural, because
there is no invocation of s that denotes the number 0. However, s
would be a selector for type Counting (the positive integers).
Indeed, one can instead define operators as follows:
Natural <--- 0;
Counting <--- s(Natural);
Natural <--- p(Counting);
where p denotes the predecessor operator. I note that with these
signatures the s and p operators are bijective, and indeed meet the
TTM requirement for being selectors on their respective declared
return types. Furthermore, there is a symmetry in the way each
operator represents the THE_component operator of the other operator.
That is not surprising of course because the THE_ operators represent
the inverse of the associated selector (i.e. they get back the values
of the possrep components that were put there by the selector). As it
stands however, it seems there is a missing ingredient which is to
specify the subtype relationship:
Counting isa Natural;
I say this is missing from the perspective of thinking of these
operator signatures as analogous to production rules of a formal
grammar. I want expressions like s(s(s(0))) to be legal. With that
analogy, type names are like non-terminal symbols, and brackets,
commas and operators (which I think are formalised already as symbols
- but I'm not completely clear on that) are the terminal symbols.
Type symbols and operator symbols are disjoint. I see the subtype
declaration "Counting isa Natural" as adding a production to the
grammar in the obvious way. Indeed, an elegant syntax would instead
be:
Natural <--- Counting;
As far as I can see, this way of thinking about inheritance aligns
perfectly with the subtype as subset-of-values approach to type
inheritance in the D&D IM.
At the moment, I regard this example as an illustration of the fact
that the "possible representation" concept adds some hoops to jump
through. I wonder whether these hoops should be there in the first
place.
For another, and in my opinion much more important illustration of why
I'm uncomfortable with the restrictions imposed by the possible
representations concept (applied at the logical level of discourse), I
refer you to the sections titled "Union types" and "Elegant and
orthogonal operators" of my first post on the thread "An alternative
to possreps". More specifically to my claim that operators on
uncountable types can be very elegant compared to the "imperfect"
versions that try to account for the finite nature of computers by
imposing what appear tantamount to possible *physical* representation
restrictions on the (abstract) types themselves.
#22
| |||||||
| |||||||
|
|
On Jun 14, 8:13 pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote: On Jun 13, 1:01 pm, David BL <davi... (AT) iinet (DOT) net.au> wrote: On Jun 13, 7:40 pm, Hugh Darwen <hughdar... (AT) gmail (DOT) 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. |
Quote:
|
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. |
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.
Quote:
|
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? |
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.
Quote:
|
The rule Hugh proposed assumes every type has at least one possible representation, which appears to outlaw types like PLANE_FIGURE. |
like PLANE_FIGURE? Please tell me it has nothing to do with
any worry you have about /physical/ representation?
Quote:
|
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). |
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?
Quote:
|
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? |
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.
Quote:
|
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". |
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
#23
| |||
| |||
|
|
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. |
unnecessarily ..."
Quote:
|
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. |
KHD
#24
| ||||||
| ||||||
|
|
On Jun 14, 11:18 am, David BL <davi... (AT) iinet (DOT) net.au> wrote: On Jun 14, 8:13 pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote: On Jun 13, 1:01 pm, David BL <davi... (AT) iinet (DOT) net.au> wrote: On Jun 13, 7:40 pm, Hugh Darwen <hughdar... (AT) gmail (DOT) 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? |
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.
Quote:
|
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. |
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.
Quote:
|
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? |
verbose selector, that no-one intends to actually use. So "outlaw" is
not the right term to use.
Quote:
|
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? |
haven't studied the relevant parts of the TTM book.
Quote:
|
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. |
Quote:
|
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.) |
practical DDL?
#25
| |||||
| |||||
|
|
On Jun 15, 10:47 pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote: On Jun 14, 11:18 am, David BL <davi... (AT) iinet (DOT) net.au> wrote: On Jun 14, 8:13 pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote: On Jun 13, 1:01 pm, David BL <davi... (AT) iinet (DOT) net.au> wrote: On Jun 13, 7:40 pm, Hugh Darwen <hughdar... (AT) gmail (DOT) 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 awell- 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. |
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 <- ... .
Quote:
|
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. |
Quote:
|
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. |
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.
Quote:
|
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. |
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.)
Quote:
|
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? |
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
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.