Re: no names allowed, we serve types only

On Feb 18, 7:44 pm, David BL <davi..._at_iinet.net.au> wrote:
> On Feb 15, 3:01 pm, Keith H Duggar <dug..._at_alum.mit.edu> wrote:
>
>
>
> > Of course if you are dealing with crippled domain support then names
> > are essential. But envision a system with rich type support. I'm
> > asking
> > if, in that world, we even need to bother with attribute names at all?
>
> I think a rich type system is desirable.  I suggest there should be as
> many types as necessary according to exactly where it is considered
> useful to test for equality.  No more and no less.
>
> For example, it isn't particularly useful to compare a person's weight
> with a person's height, so it would be reasonable to have specialised
> types like MASS_IN_KG and LENGTH_IN_METRES.  These are like copies of
> NUMBER, but the idea here would be for them to really be distinct
> types (i.e. no implicit conversions).  I think they should be strict
> subtypes of NUMBER.   They would inherit arithmetic operators from
> NUMBER, such as the signature
>
>     NUMBER  <-- NUMBER + NUMBER
>
> which appears to defeat the purpose somewhat.  E.g.  it is possible to
> add a MASS_IN_KG to a LENGTH_IN_METRES.  However this is safe because
> it returns NUMBER which cannot be implicit downcast to a more
> specialised type.
>
> Ideally the type system would add all the appropriate specialisations
> of the operators (which for example are covariant on return type).
> E.g.   a plus operator that allows two masses to be added to give a
> mass.  Strictly speaking this is a distinct operator to the plus
> operator inherited from NUMBER, so operator overloading would be
> necessary to make this practical.
>
> A curiosity is that the super-type NUMBER doesn't play the role of a
> scalar (where by scalar I mean a dimensionless quantity).  For
> example, if one tried to define a scalar multiplication like this
>
>     MASS_IN_KG  <-- NUMBER * MASS_IN_KG
>
> one would find that any specialisation of NUMBER can serve as the
> scalar.   Instead one seems to need to define a common sub-type of all
> the specialisations of NUMBER, to serve the role of a dimensionless
> number in the type system.

Types are entirely misguided approach to physical units. Much more elegant way is to operate units as if they are numbers, for example the expression 10 * kg / (10 * sec^2) is multiplication/division of 4 number-like entities. One can use the laws of associativity/ commutativity and reduce it to 1 * kg/sec^2. Received on Fri Feb 19 2010 - 06:33:47 CET