On 30 mei, 05:04, David BL <davi... (AT) iinet (DOT) net.au> wrote:
Sorry. Missed the "suppose ... is encoded in memory as a nul-
terminated string".

I meant to say that there is nothing in the concept you describe that
would make it an "invalid" (logical) possrep. In fact, ALL types can
"conceptually" be regarded as having a "STRING" possrep, which
produces the "externalization" of any value of the type. More or less
equivalent to Java's toString() method that exists for all objects.

However, in its role as a "physical possrep", there is more to it than
what you say. It is not sufficient to say "encoded as a nul-
terminated string" to determine the actual bit pattern for a value.
Because the encoding of the string itself is also relevant, and a
possible source of differences. UTF-8 gives different bit patterns
compared to UTF-16. Byte ordering conventions produce different bit
patterns for any kind of integer numbers (except the single-byte ones
of course). etc. etc. Switching the order of the X and Y components
in an encoding that is based on the (two-component) CARTESIAN possrep,
will produce different bit patterns too.

That was my point where I said "targeted to the machine" : specifying
a physical possrep requires the specification of _every single detail_
that plays a role in determining the ultimate bit pattern. So for
this reason, your CARTESIAN possrep does not qualify as a valid
physical possrep, because it is incomplete.



Oops. You're probably right. I wasn't thinking of those. UNION
types typically even will not have a POSSREP of their own (allthough
it is always possible to conceive a toString()-like POSSREP which
includes both "actual" typename and externalization-of-value. But
beware that in the Manifesto, declaring a UNION type is _not_ merely a
matter of saying :

TYPE PLANE_FIGURE IS ELLIPSE UNION POLYGON; /* where ELLIPSE and
POLYGON were formerly root types */

Strictly speaking, the Manifesto requires that "simultaneously", the
declaration of the existing root types is changed to

TYPE ELLIPSE IS PLANE_FIGURE ... , TYPE POLYGON IS
PLANE_FIGURE ... ; /* note the comma, as opposed to a semicolon */



I try to comment as little as possible on the REAL vs. RATIONAL stuff.



Well then you got it. That's how D&D define them too. I was too
restrictive where I said "selectors with no arguments", which is in
fact even nonsensical.

On May 30, 5:09 pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
I'm not sure what you are saying there. I'll try to describe how I'm
thinking about it in more detail:

Types and hence values and operators are pure mathematical
abstractions. Nested operator invocations provide an entirely
sufficient means for (logically) representing values. I find it
superfluous to introduce POSSREPs for this purpose (as though
operators are inadequate!), as well as all the other confusing and
redundant vernacular: "atomic", "encapsulated", "scalar", "structure",
"selector", "dummy type" etc. In fact I'm now thinking of POSSREPS as
merely a peculiar syntactic sugar for declaring operators.

Operators being pure abstractions must be distinguished from any
implementation as executable routines on computers. In fact operators
are the basis for data representation and not just the basis for
defining calculations to be executed. It seems as though this former
perspective was missed when the redundant idea of POSSREPS was
introduced, and yet strangely was made apparent when each POSSREP
implicitly declared a kind of operator called a selector.

Let STRING be a type. POINT and STRING are distinct types. I see no
need to complicate things by trying to formalise some notion of a
"possible representation" of POINT involving STRING. All that's
required are /explicit/ unary operators that map POINT to STRING and
vice versa.

Even though my example involved a string representation I consider it
to be a physical representation of the value

cartesian(1.34,-6.2)

and not

tostring(cartesian(1.34,-6.2)) = "(1.34,-6.2)"

since I expressly stated that a POINT value was encoded.

The way in which a region of memory is interpreted as a value depends
on some context. Given that physical representations of one type are
typically implemented in terms of physical representations of other
types, it is not generally possible to assume there is some unique
context for interpreting a region of memory as a value.


If I had said a Unicode string then I would agree the encoding needs
to be specified as well. However I specified ASCII which is a
character encoding which defines a correspondence between 7 bit binary
patterns and character symbols, and RFC20 suggests embedding in an
octet with the high order bit always 0, so I think it can be assumed
there is no ambiguity on machines with octets as the native
addressable data type.

ASCII was incorporated into the Unicode character set as the first 128
symbols, so the ASCII characters have the same numeric codes in both
sets. This allows UTF-8 to be backward compatible with ASCII. However
UTF-8 refers to a multibyte encoding of Unicode and therefore is
distinct from ASCII.


I agree that a physical representation must be well defined.


It seems awkward to need to specify one subtype relationship in two
places.

On 31 mei, 09:26, David BL <davi... (AT) iinet (DOT) net.au> wrote:
You gave an example of a representation where values of type POINT are
denoted in some kind of textual way. I merely said there is nothing
to this construct that would somehow render it "unacceptable" as a
(logical) possrep.



??????? Not following you at all.

Operators are themselves functions thus relations, thus values !!!

RELATION PLUS {{1,1,2} {1,2,3} {2,1,3} ...}

In what way do you see a "nested operator invocation" being able to,
or being needed to, represent the value "INTEGER 1" ?



That might not be so terribly wrong, allthoug I personally think this
particular "peculiar syntactic sugar" is quite convenient.



I don't see your point.

At the very least, I can assure you that D&D are quite aware that
operators as such are "abstract" things, and that there is therefore a
"model vs. implementation" wall between the operators as abstract
mathematical objects (see "operators are relations"), and the
implementing executable code.



Where is the complication ? The mapping operator exists in either
scenario and does the same thing in either scenario.



Yes. But see my remark in that other thread about my confusing
between the peculiarities of **Tutorial** D, and the Manifesto per se.

On Jun 6, 9:50 pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
I don't understand (how a physical representation can ever be regarded
as a logical representation, if that's what you mean).


The purpose of the schema is to define, at a logical level of
discourse, the values that can legally be encoded in the database.
Clearly we are not very interested in representations of values that
we never intend to encode as data.

I agree that operators can be regarded as values, and it would be
useful in certain cases for a database to be able to encode them as
data, and make use of operators that apply to other operators, such as
function composition 'o' in order to form expressions like (fog)(x).
However this seems somewhat irrelevant to the point being made.


I described how nested operator invocations can represent natural
numbers in the topic "An alternative to possreps". Just two operators
are sufficient:

Natural <--- 0;
Natural <--- s(Natural);

0 is a nullary operator. s is a unary operator that gives the
successor. The INTEGER 1 is represented logically by s(0).

Whilst a rich set of predefined types is preferred in a real system,
in principle there is no need to bootstrap the logical level of
discourse with implicit possible representations of predefined types.


Convenient in what sense? For example, do you believe it involves
fewer keystrokes? Is it a convenient way of grouping operators?


I'm only guessing at the reasons why POSSREPS were introduced when
they seem unnecessary.

I agree that D&D are quite aware that operators are abstract. I didn't
express myself very clearly. Consider that we define "operation" to
mean an invocation of an operator with particular values of the
arguments. I would expect for many software developers this word
suggests computation is involved and I think this reflects some kind
of bias, i.e. that (abstract) operations are associated with process
and not data. I don't think it is customary to think of recorded data
itself as representing instances of (abstract) operations.


It is simpler to only define the operators. I can think of many ways
in which POSSREPS add complexity. E.g. DDL grammar is more complex.

On May 26, 5:04*am, David BL <davi... (AT) iinet (DOT) net.au> wrote:
David BL cites an example from that book and asks a lot of questions
about possreps, sometimes using phrasing such as "Does Date think
that ...", "Is it Date's position that ...".

The possrep concept arose in a joint work by me and Chris Date: "The
Third Manifesto", which Erwin Smout has correctly referred to in his
responses, both in this thread and the earlier one on David BL's
alternative proposal. I have not had time to study the entire
discussions in detail but I know Erwin understands our work very well
and I doubt whether I would disagree with any of his responses.

David: I'm just wondering if you've actually been able to study The
Third Manifesto, our proposed Inheritance Model, and the detailed
rationales and discussions we have given in our books on this
subject. The official versions of TTM and the IM are now in "Database
Explorations" (Trafford, 2010) but "Databases, Types, and The
Relational Model" (Addison-Wesley, 2007) is probably more useful
because it contains the detailed discussions whereas the later book
just explains why we made certain minor changes in the latest
versions. If you haven't, you may find that those discussions give
you answers to many of your questions. Also, my website www.thethirdmanifesto.com
contains some material you might find useful, include the bare bones
of TTM and the IM.

For now, I just hope the following points about possreps and selectors
are clear:

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.

2. A possrep declaration is a way of defining a signature for a
selector, along with a constraint (just like your own proposed
definition for numerical division, which includes a constraint to the
effect that the divisor, a value of type real, must not be zero).
(Btw, your idea of applying a constraint on the parameters of any
operator is one that I don't think occurred to me and Date, and I find
it interesting.)

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.

4. If a selector S is defined by a possrep declaration, then the
parameters for S correspond to the components of the possrep. We
assume that if two invocations of S differ in at least one argument,
then those two invocations denote different values. Thus, if we take
possrep CARTESIAN(X REAL, Y REAL) for type POINT, then the operators
THE_X(P POINT) and THE_Y(P POINT) are well defined: every point has
exactly one X value and exactly one Y value. We assume that the
declaration of such a possrep guarantees that users of the type in
question will be able to develop whatever operators they desire for
that type. (So, yes, a canonical form is needed in cases like the
numerator/denominator possrep for type RATIONAL. That could be
addressed in the physical representation, such that
THE_NUM(RATIONAL(2,4)) and THE_DEN((RATIONAL(2,4)) yield 1 and 2,
respectively--a bit of a tall order! It could also be addressed by a
constraint on the possrep.

Some people have argued that selectors aren't always needed--in other
words, they don't mind allowing a type to contain values that cannot
be denoted by a single expression in the language. We admit that in
practice nobody would want to invoke a selector to denote the entire
content of the film "Gone with The Wind", a value of type Video, but
we still think a well-designed language should make that a theoretical
possibility. I don't think we could disagree with an alternative
model that meets the same objectives as I have outlined above, nor
would we necessarily disagree with one that fails to meet them but is
perhaps intended for rather less general use, so long as its
deficiencies and advantages are clear.

Hugh Darwen

On Jun 13, 7:40 pm, Hugh Darwen <hughdar... (AT) gmail (DOT) com> wrote:
I agree that Erwin is very knowledgeable.


I have a copy of Date's Introduction book, but not the other books
that are relevant. I've read a good deal of the online material
referenced by the TTM web site, so for example I'm familiar with the
RM prescriptions, your paper "Towards an Agreeable Model of Type
Inheritance" and looked at the grammar of Tutorial D on occasion.
However, I certainly don't have an in depth knowledge of the TTM, nor
the "detailed rationale" that you speak of.

BTW I think the IM is very impressive.


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.


Agreed. I also see a possrep as declaring a set of THE_ operators, and
pseudovariables provide a convenient shorthand for specifying certain
updates.


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


I can understand that it's important for the THE_ operators to be well
defined, so I agree with your approach. Another advantage is that the
equality operator is implicitly defined.

I assume the downside is that the canonical form is imposed on the
selectors. i.e. they may have constraints that make them harder to
use, and this might be a source of surprise and annoyance for users,
such as when a polar representation of a complex number fails because
the phase wasn't in the canonical range.


I agree that the aim should be that any value can be represented by a
single expression in the language.

On Jun 14, 1:01 am, David BL <davi... (AT) iinet (DOT) net.au> wrote:
It occurred to me that this item which is part of RM prescription 4
must be an example of a prescription that must be modified slightly
when you incorporate the IM (Erwin warned me about this). I don't
have the TTM book so I cannot confirm that at the moment.

I consider my proposal to include your ideas on type inheritance, so I
prefer to only consider the version of the TTM that includes the IM.
I'll try to take that into account when I refer to the online TTM.

On Jun 13, 1:01*pm, David BL <davi... (AT) iinet (DOT) net.au> wrote:
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.

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

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.

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.

No, that is wrong. Any value can be represented by /at least
one/ single expression. Above Hugh Darwen was discussing one
particular selector S, there are arbitrarily many other
selectors S1, S2, S3, ...

KHD

On Jun 14, 8:13 pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:
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.

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.


I have D&D's inheritance model in mind. In what sense are you blaming
something on inheritance?

The rule Hugh proposed assumes every type has at least one possible
representation, which appears to outlaw types like PLANE_FIGURE. I
assume Hugh would see this as justifiable in the version of TTM
without an inheritance model. However I note that in principle there
is nothing to stop one from defining a POSSREP of PLANE_FIGURE that
works in the manner of a discriminated union (i.e. with a 'tag'
component that indicates which one of a finite number of kinds of
figures is represented, and the other components are used in some
adhoc manner for things like the radius of a circle, perhaps using
zeros when they are inapplicable to satisfy the canonical form
requirement). This is obviously ugly and impractical - leading to a
verbose selector for example. It follows therefore that D&D would
see that the IM is an important extension to the basic TTM.

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

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


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?


I think there is an ambiguity in what 'single' was intended to mean.
I thought when Hugh said 'single' he instead meant that a single
expression was able to denote a value (rather than multiple
expressions somehow all being required to represent the value, even a
very complicated one).

On Jun 13, 6:01*pm, David BL <davi... (AT) iinet (DOT) net.au> wrote:
[...]
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