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=2.1 required=5.0 tests=BAYES_20,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,fcdd0f6139250dc5
X-Google-Attributes: gid103376,public
From: Tom Moran <tmoran@bix.com>
Subject: Re: Tagged Types and Generics
Date: 1997/04/28
Message-ID: <33656887.E40@bix.com>#1/1
X-Deja-AN: 238084640
References: <3.0.32.19970421225247.007129f4@mail.4dcomm.com>
 <EACHUS.97Apr28152546@spectre.mitre.org>
Organization: InterNex Information Services 1-800-595-3333
Reply-To: tmoran@bix.com
Newsgroups: comp.lang.ada
Date: 1997-04-28T00:00:00+00:00
List-Id: <comp.lang.ada>


Some context on this problem might help:
To make a little demo, some source code of which could appear in
illustrations in the article,  we made a Purchase Order package,
and to demonstrate internationalization included:

generic
  type Currencies is delta <> digits <>;
  Currency_Pic_String: String;
...

so it could be instantiated by

  type Dollars is delta 0.01 digits 7;
  package USA_PO_Entry is new PO_Entry(Dollars, "$$$_$$9.99" ...
etc.

But then if you want to decide at run time which country you are in,
you need a case statement, for instance:
  when USA   => USA_PO_Entry.Start;
  when Japan => Japan_PO_Entry.Start;
  when Italy => Italy_PO_Entry.Start;

Clearly this is exactly the 'ever growing case statements' situation
that is one motivation for tagged types.  Unfortunately, the
parameters to "delta <> digits <>" must be specified in a generic
instantiation and must be known at compile time, while the facts
about a particular country's currency may change at run time.  Three
solutions that suggest themselves to me are:

1) Instantiate the generic once for currencies whose smallest unit
is 0.01, once for 0.1, once for 1.0 etc (is Lira really always a
multiple of 100?) and then at run time use a case statement with
just a few fixed branches based on that scaling.  This does not
look very elegant.

2) Forget the generic decimal type and instead always use a single
predefined one that's "big enough" and explicitly do appropriate
rounding as well as picture clause output.  This almost amounts
to doing your own fixed point scaled arithmetic, which seems a
waste.

3) type Currencies is abstract;
   function "+" ...

   type Dollars is delta 0.01 digits 7;
   package US is new Money_Arithmetic(Dollars, ...

where Money_Arithmetic creates Currency, a descendant of Currencies
with appropriately defined operations and one can then declare

   Price, Cost : US.Currency;

Then if the Congo rejoins the monetary system only a limited number
of changes need be made to the system.  But this seems rather a
heavy handed and probably storage and processing intensive approach.


Better solutions?