Re: An alternative to possreps

From: David BL <davidbl_at_iinet.net.au>
Date: Fri, 17 Jun 2011 07:52:29 -0700 (PDT)
Message-ID: <c4a64394-c265-4922-95d2-9d24f603f041_at_p9g2000prh.googlegroups.com>


On Jun 17, 8:15 pm, Hugh Darwen <hughdar..._at_gmail.com> wrote:
> David BL and I have been exchanging emails privately in the past few
> days and we have reached a common understanding and agreement. I hope
> the following expresses that agreement.
>
> TTM is not at all concerned with syntax. It uses the terms "selector"
> and "possrep" to define concepts on which to base the semantics of
> certain operators that it proposes to be required in connection with
> every type. A selector for type T is a bijective function (assuming a
> canonical form for its domain), mapping possrep values to values of
> type T and vice versa. It is the inverse mapping that allows our
> "THE_" operators to be defined for each possrep component.
>
> The motivation for requiring such operators is (a) to guarantee that
> every value can be denoted by a literal (an expression in which no
> variables are referenced), and (b) to guarantee that sufficient
> primitive operators are available for the defining of any further
> operators that users of T might require.
>
> An assessment of TTM and our IM could question our motivation: are
> those guarantees really necessary? If the answer is "yes", then it
> could go on to question whether TTM really does meet them, with or
> without the IM.
>
> David doesn't disagree with our motivation. Moreover, his proposal is
> concerned with syntax rather than semantics and his aim is a laudable
> one: proper separation of concerns. In Tutorial D, our syntax for
> user-defined scalar types uses explicit POSSREP declarations from
> which the required operators are automatically generated by the system
> (you can try them out with Dave Voorhis's Rel, an implementation of
> Tutorial D). Well, Tutorial D was expressly designed to illustrate
> our proposals, so that was an obvious approach to take. In David's
> proposal, a type is defined by a bunch of operator signatures under an
> assumption that the semantics for these operators are defined
> elsewhere. If those semantics can be shown to address my points (a)
> and (b), then such a type conforms to TTM; otherwise, it doesn't.
>
> Thus, I would agree that David's proposal is a possible replacement
> for Tutorial D's way of defining scalar types, but it doesn't yet do
> the job of guaranteeing those required semantics.
>
> Okay, David?

Indeed, that's an excellent description. Received on Fri Jun 17 2011 - 16:52:29 CEST

Original text of this message