Re: An alternative to possreps

On Jun 9, 2:28 am, David BL <davi..._at_iinet.net.au> wrote:
> On Jun 8, 3:17 pm, Bob Badour <b..._at_badour.net> wrote:
> > David BL wrote:
> > > On Jun 7, 9:49 pm, Bob Badour <b..._at_badour.net> wrote:
>
> > >>David BL wrote:
>
> > >>>On Jun 6, 9:26 pm, Erwin <e.sm..._at_myonline.be> wrote:
>
> > >>>>On 31 mei, 11:54, David BL <davi..._at_iinet.net.au> wrote:
>
> > >>>>>Is there anything in TTM that prohibits one from making every type a
> > >>>>>dummy type?  Would that make it essentially the same approach which
> > >>>>>I've described?
>
> > >>>>Not "in TTM".  What prohibits this is "reality", I'd rather say.
>
> > >>>>If you're interested in a subset of T, then you can't define this
> > >>>>subset by means of UNIONs involving T.
>
> > >>>Yes, but that is not a problem.  Let Ellipse be a "dummy type".  If
> > >>>you're interested in a subtype Circle of Ellipse then you can simply
> > >>>declare Circle as another dummy type. I'm assuming you can declare
> > >>>subtype relationships between dummy types.  In my approach you use
> > >>>these declarations:
>
> > >>>    type Ellipse;
> > >>>    type Circle;
> > >>>    Circle isa Ellipse;
>
> > >>>I consider types like Circle and Ellipse to be defined by their
> > >>>operators.  In that sense there is no problem treating all types as
> > >>>"dummy types".
>
> > >>Either the operators define the equivalent of possreps or the type model
> > >>  doesn't really describe ellipses and circles. So what are you trying
> > >>to achieve?
>
> > > I'm suggesting the operators define the equivalent of possreps.
> > > Possreps are redundant.
>
> > How do operators express that center is held invariant when changing
> > only radius? And vice versa?
>
> > Or perhaps more clearly with complex number types: How do operators
> > express that phase is held constant when changing only magnitude? And
> > vice verse. Even though both realPart and imaginaryPart change?
>
> I agree that update operators are an important consideration.
>
> Nevertheless I don't think type systems per se should have anything to
> do with specifying what update operators are available on variables. I
> consider a type to be a set of values plus operators on *values* (or
> what Date calls read-only operators). This simplifies things and
> separates concerns (because one can model what values can be encoded
> in the database independently of the myriad ways the database variable
> may change over time).

1. algebraic type systems do not just specify operators they specify /axioms/. Without the axioms all you have is syntax devoid of any useful semantics.
2. you are far behind the curve and simply reinventing and/or rediscovering (sloppily) what is already covered thoroughly in conventional type theory literature. Specifically this:

   "I don't think type systems per se should have anything to     do with specifying what update operators are available on     variables."

is hopefully a joke.

KHD Received on Mon Jun 13 2011 - 16:30:40 CEST