Re: Questions on possreps

From: Erwin <e.smout_at_myonline.be>
Date: Mon, 6 Jun 2011 06:50:24 -0700 (PDT)
Message-ID: <1574535f-bd30-4c65-9ead-6053f02d99ce_at_z13g2000yqg.googlegroups.com>


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.

> 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} ...} In what way do you see a "nested operator invocation" being able to, or being needed to, represent the value "INTEGER 1" ?

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

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

> 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 seems awkward to need to specify one subtype relationship in two
> places.

Yes. But see my remark in that other thread about my confusing between the peculiarities of **Tutorial** D, and the Manifesto per se. Received on Mon Jun 06 2011 - 15:50:24 CEST

Original text of this message