Re: An alternative to possreps

From: David BL <davidbl_at_iinet.net.au>
Date: Wed, 8 Jun 2011 23:28:12 -0700 (PDT)
Message-ID: <179f8e2c-a1f2-4a50-9022-c8910c68ff13_at_s16g2000prf.googlegroups.com>


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

ISTM an advantage of thinking of type systems in this restricted way is that it promotes a powerful, useful and straightforward form of logical independence that is only concerned with read only views of the data, noting that typically only a small proportion of the functionality of applications is concerned with mutations to data. Logical independence of updateable views is crippled by comparison.

Update operators can be modelled at the logical level of discourse using a language allowing variables to be passed by reference in some sense. E.g.

    setmagnitude(Complex& c, Real m)
    {

        c := polar(m,phase(c));
    }

In a way that directly answers your question. However I think this oversimplifies things because database variables exist in time and space and are therefore associated with the physical implementation. That begs the question of how it fits in with constraint checking, atomicity, concurrency, transactions, locking, data replication and synchronisation etc. Clearly it's useful to aim for physical and logical independence, but I don't think it's as straightforward as with the type system in its restricted sense. For example, in a system using Operational Transformation the way in which updates are expressed on a variable affects the result of merging concurrent updates. Received on Thu Jun 09 2011 - 08:28:12 CEST

Original text of this message