From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cc4f25d878383cc
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-12-06 16:55:39 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: byhoe@users.sourceforge.net (Adrian Hoe)
Newsgroups: comp.lang.ada
Subject: Re: Another Idea for Ada 20XX
Date: 6 Dec 2001 16:55:38 -0800
Organization: http://groups.google.com/
Message-ID: <45601fc.0112061655.29c31a48@posting.google.com>
References: <mailman.1007322723.31592.comp.lang.ada@ada.eu.org>
 <3C0AACCE.329CFB60@worldnet.att.net>
 <45601fc.0112031740.3e217c8a@posting.google.com>
 <uIRfutYmai5V@eisner.encompasserve.org>
 <3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com>
 <3C0EF0A0.9F42EDB4@adaworks.com> <3C0FAD3D.64ACC870@usa.com>
NNTP-Posting-Host: 210.186.172.14
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1007686539 23375 127.0.0.1 (7 Dec 2001 00:55:39
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 7 Dec 2001 00:55:39 GMT
Xref: archiver1.google.com comp.lang.ada:17548
Date: 2001-12-07T00:55:39+00:00
List-Id: <comp.lang.ada>

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.