Re: An alternative to possreps

From: Hugh Darwen <hughdarwen_at_gmail.com>
Date: Fri, 17 Jun 2011 05:15:20 -0700 (PDT)
Message-ID: <14cf1c36-727a-4a69-869b-5037ca89e917_at_q30g2000yqb.googlegroups.com>


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?

Hugh Darwen Received on Fri Jun 17 2011 - 14:15:20 CEST

Original text of this message