Re: Tagged Types and Generics

[Tom Moran <tmoran@bix.com>]

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?