Re: Questions on possreps

From: David BL <davidbl_at_iinet.net.au>
Date: Tue, 7 Jun 2011 02:40:07 -0700 (PDT)
Message-ID: <8a2cb4ab-5d8b-412c-b69e-98eb01b71626_at_r27g2000prr.googlegroups.com>


On Jun 6, 9:50 pm, Erwin <e.sm..._at_myonline.be> wrote:
> On 31 mei, 09:26, David BL <davi..._at_iinet.net.au> wrote:
>
> > I'm not sure what you are saying there.
>
> 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.

I don't understand (how a physical representation can ever be regarded as a logical representation, if that's what you mean).

> > Types and hence values and operators are pure mathematical
> > abstractions. Nested operator invocations provide an entirely
> > sufficient means for (logically) representing values.
>
> ??????? Not following you at all.
>
> Operators are themselves functions thus relations, thus values !!!
>
> RELATION PLUS {{1,1,2} {1,2,3} {2,1,3} ...}
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.

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

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.

> > 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.
>
> That might not be so terribly wrong, allthoug I personally think this
> particular "peculiar syntactic sugar" is quite convenient.

Convenient in what sense? For example, do you believe it involves fewer keystrokes? Is it a convenient way of grouping 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.
>
> 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.

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.

> > 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.
>
> Where is the complication ? The mapping operator exists in either
> scenario and does the same thing in either scenario.

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. Received on Tue Jun 07 2011 - 11:40:07 CEST

Original text of this message