Re: Another Idea for Ada 20XX

[byhoe@users.sourceforge.net (Adrian Hoe)]

Wes Groleau <wgroleau@usa.com> wrote in message news:<3C0FAD3D.64ACC870@usa.com>...
> 
>   function "+" (Left   : Meters;
>                 Right  : Kilometers)
>                 return : Meters;



Consider this:

function "+" (Left   : Meters;
              Right  : Inches)
              return Meters;

What kind of precision in the conversion of Inches to Meters if Unit
Checking and Conversion are to be part of Ada? Do I/we have the
liberty to select the precision I/we want?

How exactly this will be implemented by the new annex of Ada
(perhaps)?


                                                  -- Adrian Hoe


> Also, this method does not allow attributes
> and it makes literals slightly more clumsy at best,
> worse if you consider all the possible ways you can
> misspell a unit name or use an unrecognized abbreviation
> for it.  (Of course the latter might also be a problem
> in a "language feature.")
> 
> I once used an enumerated type for supported units,
> another for all allowed ways of writing them,
> a lookup table for standard_form (allowed_written_form),
> and loads of lookup tables for conversion factors,
> which type comes from what, etc.  That allowed having
> only one actual type, and only one moderately sized
> function per operator, but the tables took up a lot
> of space.  Extension and inheritance might have helped
> some but not a lot.  In that particular application,
> the lack of attributes turned out to be only a minor
> inconvenience, but I would think it would mean a lot
> in other cases.
> 
> Defining a new metric type by inheritance would require
> knowing all units in the inheritance tree that it could
> interact with, and providing or overriding the operators
> to work AND disabling all the operators that would make
> illegal operations.
> 
> So I think it wouldn't help any over a non-inherited way.