Re: Tagged Types and Generics

Re: Tagged Types and Generics

[Robert C. Leif, Ph.D.]

To: Nick Roberts et al.
From: Bob Leif

I am absolutely in agreement with you and what you posted below!  I was
going to add the last_update date and time to money. The discussion has
never been tagged types versus generics.  It has been about constructing a
tagged type with generic fields and instantiating a generic with a tagged
type which can include generic fields.  Both constructs are very useful and
should NOT be mutually exclusive.  Unfortunately, I do not know how to do
it.  Even if Nick Roberts and I are both dead wrong on money, it is still
necessary to explain how to combine tagged types with generics.

I might add that part of the problem is historical. The text books first
explain generics, which existed in Ada 83 and then the Ada 95 addition,
tagged types.  I have not seen a generic in a tagged type with a class-wise
procedure or operator. Is very nice to start with a money tagged type and
then create many children: US_Dollars, Canadian_Dollars, Yen,
Deutsch_Marks, Italian_Lira, Turkish_Lira, Gold_Oz, etc. This is much
cleaner than a variant record with over 50 values for the discriminant.  A
tagged type also provides the possibility of using wide characters and
different methods for showing negative values.

-------------------------------------------------------------
Date:    Sun, 27 Apr 1997 00:49:14 GMT
From:    Nick Roberts <Nick.Roberts@DIAL.PIPEX.COM>
Subject: Re: Tagged Types and Generics

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.862004577@merv>...
> Bob Leif says
>
> <<Background: Recently, Tom Moran, Randy Brukard and I wrote a paper.
"Ada
> 95, The Language Speaks for Itself".  This paper will appear in the May
> Object Magazine.  In this paper we modeled money as a decimal type and
did
> inheritance directly via a generic.  I had suggested modeling money as a
> tagged type.  My co-authors very wisely vetoed that approach.  After
the>>
>
> I can't see any reason for wanting to model money as a tagged type -- you
> lose literals, and you lose a lot of other useful semantics of decimal
> types, and you gain nothing  that I can see.


I think I can see a few possibilities: for example, what if you wanted to
be able to use multiple currencies easily? You can get literals reasonably
easily by the use of simple conversion functions. For example:

package Money is
   type General_Monetary_Amount is limited private;
   type US_Dollars is delta 0.01 digits 12;
   type Lire is delta 100 digits 14;
   ...
   function To_General(Amount: in US_Dollars) return
General_Monetary_Amount;
   function To_General(Amount: in Lire) return General_Monetary_Amount;
   ...
private
   ...
end;

and then a 'literal' can be constructed with something like

To_General(US_Dollars'(59.23))

This is slightly clumsy, of course, but not too bad.

If we had defined General_Monetary_Amount as tagged, we could extend it,
perhaps to provide a date (for aiding exchange calculations):

package Money.Dated is
   type Dated_Monetary_Amount is new General_Monetary_Amount;
   ...
private
   type Dated_Monetary_Amount is new General_Monetary_Amount with
      record
         Date: Calendar.Time;
      end record;
end;

And so on. Just thoughts (and it's gone midnight).

Nick.

------------------------------

Re: Tagged Types and Generics

[Robert Dewar]

Robert Leif said

<<I might add that part of the problem is historical. The text books first
explain generics, which existed in Ada 83 and then the Ada 95 addition,
tagged types.  I have not seen a generic in a tagged type with a class-wise
procedure or operator. Is very nice to start with a money tagged type and
then create many children: US_Dollars, Canadian_Dollars, Yen,
Deutsch_Marks, Italian_Lira, Turkish_Lira, Gold_Oz, etc. This is much
cleaner than a variant record with over 50 values for the discriminant.  A
tagged type also provides the possibility of using wide characters and
different methods for showing negative values.>>

I disagree, this is using a shotgun to kill an ant. Simple derivation is
perfectly fine for dealing with different kinds of currency. Sure you
can tag with the type, but about all that buys you is a display routine
that puts FF or UKL in as appropriate, and that's not worth the heaviness
of using tagged types in this connection.

I prefer to keep thinks as light and simple as possible (I must say that
in general it surprises me how many Ada programmers have a great love of
complex abstraction mechanisms, and seem to delight in trying to use
all kinds of complex features all over the place -- I am not talking
of Robert's suggestoin specifically here, but just reacting to some of
the code we see submitted to us -- I guess people must find the GNAT
code very simple minded -- one of my students said it was "painfully
easy to read" :-) :-)

Re: Tagged Types and Generics

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.862144456@merv>...
[...]
[of GNAT code]
> code very simple minded -- one of my students said it was "painfully
> easy to read" :-) :-)
> 


Amen to "painfully easy to read" code, in any language!!!

Nick.

Tagged Types and Generics

[Robert C. Leif, Ph.D.]

From: Bob Leif, Ph.D.

To: Comp.Lang.Ada
Date: 21 April, 1997
Subject: Tagged Types and Generics.

Background: Recently, Tom Moran, Randy Brukard and I wrote a paper. "Ada
95, The Language Speaks for Itself".  This paper will appear in the May
Object Magazine.  In this paper we modeled money as a decimal type and did
inheritance directly via a generic.  I had suggested modeling money as a
tagged type.  My co-authors very wisely vetoed that approach.  After the
paper was submitted, I attempted to do my suggestion and model money as a
tagged type with the child libraries being the different currencies.  If
one makes the exchange rate a decimal type, then currency conversion
requires a decimal division of the same field from two of the child library
units.  I created a function with class based types and tried to
instantiate the generic procedure Divide in the Annex F Package
Ada.Decimal.  My lack of success is described in the listing of the body
below.  The program has been reduced and modified to demonstrate the
problem.  I know that I could probably get away with using a floating point
type.  However, if we are to sell Ada to the MIS world based in part on its
capacity to do decimal arithmetic, then we should employ decimal arithmetic
in our programs.

I do not know how to pass the type an element in a tagged record to a
generic.  I tried recreating the type by including the values of the Scale
and Digits attributes in the tagged record.  I would appreciate suggestions
and hope for a solution that I could show at the ACM SigAda booth at Object
Expo in New York City from 2-5 June, 1997.

Both the specification and body were compiled under GNAT for Windows.
gcc -c -gnatlv dec_divide.adb > dec_divide.txt

Specification source.

  generic

      type Num_Or_Denom is delta <> digits <>;
      type Ratio is delta <> digits <>;

      package Dec_Divide is

      type Num_Or_Denoms is abstract tagged private;
     --This the start of the class

    Function Ratio_Test(Numerator : in Num_Or_Denoms'Class;
                        Denominator : in Num_Or_Denoms'Class)
                        return Ratio;
Private
      type Num_Or_Denoms is abstract tagged
            record
            The_Num_Or_Denom : Num_Or_Denom;
            Num_Or_Denom_Scale: Integer := Num_Or_Denom'Scale;
            Num_Or_Denom_digits: Integer := Num_Or_Denom'digits ;
                         end record;
   end Dec_Divide;

----------------------------------------------------------------------------
------------------------------
Listing of body.
GNAT 3.09 (970121) Copyright 1991-1996 Free Software Foundation, Inc.

Compiling: dec_divide.adb (source file time stamp: 1997-04-22 05:24:59)

     1. -- From Ada 95 Referance Manual pages 47-48 Section 3.5.10
     2. -- S'Scale
     3. -- S'Scale denotes the scale of the subtype S, defined as the
     4. -- value N such that S'Delta = 10.0**(-N). The scale indicates
     5. -- the position of the point relative to the rightmost
     6. -- significant digits of values of subtype S. The value
     7. -- of this attribute is of the type universal_integer.
     8.
     9. -- Note 38. S'Scale is not always the same as S'Aft for a
    10. -- decimal subtype; for example, if S'Delta = 1.0 then S'Aft
    11. -- is 1 while S'Scale is 0.
    12.
    13. --S'Digits
    14. --S'Digits denotes the digits of the decimal fixed point subtype S,
    15. --which corresponds to the number of decimal digits that are
    16. --representable in objects of the subtype. The value of this attribute
    17. --is of the type universal_integer.
    18.
    19. -- Note 39. The predefined operations of a fixed point type
    20. -- include the assignment operation, qualification,
    21. -- the membership tests, and explicit conversion to and
    22. -- from other numeric types. They also include the relational
    23. -- operators and the following predefined arithmetic operators:
    24. -- the binary and unary adding operators - and +,
    25. -- multiplying operators, and the unary operator abs.
    26.
    27.    with Ada.Decimal;
    28.
    29.    package body Dec_Divide is
    30.       Function Ratio_Test(Numerator : in Num_Or_Denoms'Class;
    31.                           Denominator : in Num_Or_Denoms'Class)
    32.       return Ratio is
    33.
    34.       --This may require access types for the decimals types, which
are
    35.       --dynamic rather than static. Maybe define box with a generic
in the
    36.       --specification and pass over. With a pointer, one gets a
general
    37.       --structure.
    38.
    39.          Type Gen_Numerator is delta
10.0**(-Numerator.Num_Or_Denom_Scale)
                                                 |
        >>> non-static expression used for delta value

    40.                 digits Numerator.Num_Or_Denom_digits;
                                        |
        >>> non-static expression used for digits value

    41.
    42.          Type Gen_Denominator is delta 10.0**(-
        Denominator.Num_Or_Denom_Scale)
                                                   |
        >>> non-static expression used for delta value

    43.                         digits Denominator.Num_Or_Denom_digits;
                                                  |
        >>> non-static expression used for digits value

    44.
    45.
    46.          Procedure Divide is new Ada.Decimal.Divide
    47.            (Dividend_type => Gen_Numerator,
    48.             Divisor_Type  => Gen_Denominator,
    49.             Quotient_Type => Ratio,
    50.             Remainder_Type => Ratio);
    51.
    52.          Use Divide;
                     |
        >>> "Divide" is not a usable package

    53.       The_Numerator: Gen_Numerator :=
                Gen_Numerator(Numerator.The_Num_Or_Denom);
    54.
    55.       The_Denominator:Gen_Denominator :=
                Gen_Denominator(Denominator.The_Num_Or_Denom);
    56.          The_Ratio: Ratio;
    57.          The_Remainder: Ratio;
    58.       begin --Ratio_Test
    59.
    60.          Divide
    61.             (Dividend => The_Numerator,
    62.             Divisor =>  The_Denominator,
    63.             Quotient => The_Ratio,
    64.             Remainder => The_Remainder);
    65.         Return The_Ratio;
    66.       end Ratio_Test;
    67.    end Dec_Divide;

 67 lines:

 Robert C. Leif, Ph.D., PMIAC
Vice President & Research Director
Ada_Med, a Division of Newport Instruments
5648 Toyon Road
San Diego, CA 92115-1022
Tel. & Fax (619) 582-0437
E-mail rleif@rleif.com

Re: Tagged Types and Generics

[Jeff Carter]

Robert C. Leif, Ph.D. wrote:
>...
>   generic
> 
>       type Num_Or_Denom is delta <> digits <>;
>       type Ratio is delta <> digits <>;
> 
>       package Dec_Divide is
> 
>       type Num_Or_Denoms is abstract tagged private;
>      --This the start of the class
> 
>     Function Ratio_Test(Numerator : in Num_Or_Denoms'Class;
>                         Denominator : in Num_Or_Denoms'Class)
>                         return Ratio;
> Private
>       type Num_Or_Denoms is abstract tagged
>             record
>             The_Num_Or_Denom : Num_Or_Denom;
>             Num_Or_Denom_Scale: Integer := Num_Or_Denom'Scale;
>             Num_Or_Denom_digits: Integer := Num_Or_Denom'digits ;
>                          end record;
>    end Dec_Divide;

I don't see any point to this. All objects in Num_Or_Denoms'Class have
the same type for component The_Num_Or_Denom, and the same default
values for components Num_Or_Denom_Scale and Num_Or_Denom_Digits.

>     46.          Procedure Divide is new Ada.Decimal.Divide
>     47.            (Dividend_type => Gen_Numerator,
>     48.             Divisor_Type  => Gen_Denominator,
>     49.             Quotient_Type => Ratio,
>     50.             Remainder_Type => Ratio);
>     51.
>     52.          Use Divide;
>                      |
>         >>> "Divide" is not a usable package

This instantiation creates a procedure. You can't "use" a procedure.

If you could do it, this would be the same as

   procedure Divide is new Ada.Decimal.Divide
      (Dividend_Type  => Num_Or_Denom,
       Divisor_Type   => Num_Or_Denom,
       Quotient_Type  => Ratio,
       Remainder_Type => Ratio);

unless you somehow changed the values of the components
Num_Or_Denom_Scale and Num_Or_Denom_Digits. Perhaps you had planned on a
way to do this, but it's not clear from your post.

Even if you change these values, the numbers you are dividing are still
of type Num_Or_Denom, and your result of type Ratio. You are simply
performing a conversion to another type, equivalent to:

   type Z is delta A digits B;
   type Y is delta C digits D;
   type X is delta E digits F;
   type W is delta G digits H;

   procedure Divide is new Ada.Decimal.Divide (Dividend_Type  => Y,
                                               Divisor_Type   => X,
                                               Quotient_Type  => W,
                                               Remainder_Type => W);

   Dend : Z;
   Sor  : Z;
   Quot : W;
   Rmdr : W;
   ...
   Divide (Dividend  => Y (Dend),
           Divisor   => X (Sor),
           Quotient  => Quot,
           Remainder => Rmdr);

Watch out for the auntie-spam return address.
-- 
Jeff Carter  ( carter @ innocon . com )  PGP:1024/440FBE21

"Now go away, or I shall taunt you a second time." Monty Python & the
Holy Grail

Re: Tagged Types and Generics

[Robert Dewar]

Bob Leif says

<<Background: Recently, Tom Moran, Randy Brukard and I wrote a paper. "Ada
95, The Language Speaks for Itself".  This paper will appear in the May
Object Magazine.  In this paper we modeled money as a decimal type and did
inheritance directly via a generic.  I had suggested modeling money as a
tagged type.  My co-authors very wisely vetoed that approach.  After the>>

I can't see any reason for wanting to model money as a tagged type -- you
lose literals, and you lose a lot of other useful semantics of decimal
types, and you gain nothing  that I can see.

Re: Tagged Types and Generics

[Tom Moran]

It's an interesting problem because it certainly does seem at first
blush that money should be a tagged type - a number with a tag saying
what currency it is.  But in terms of actual use, it doesn't work out at
all well.  Perhaps it's a good candidate for a textbook example.

Re: Tagged Types and Generics

[Matthew Heaney]

In article <dewar.862004577@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Bob Leif says
>
><<Background: Recently, Tom Moran, Randy Brukard and I wrote a paper. "Ada
>95, The Language Speaks for Itself".  This paper will appear in the May
>Object Magazine.  In this paper we modeled money as a decimal type and did
>inheritance directly via a generic.  I had suggested modeling money as a
>tagged type.  My co-authors very wisely vetoed that approach.  After the>>
>
>I can't see any reason for wanting to model money as a tagged type -- you
>lose literals, and you lose a lot of other useful semantics of decimal
>types, and you gain nothing  that I can see.

Agreed.  Derivation is a much more natural technique for modeling different
currencies.  See section 7.3 of the Ada 83 Rationale which uses that very
example.

<http://sw-eng.falls-church.va.us/AdaIC/standards/83rat/html/ratl-07-03.html
#7.3>

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Tagged Types and Generics

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.862004577@merv>...
> Bob Leif says
> 
> <<Background: Recently, Tom Moran, Randy Brukard and I wrote a paper.
"Ada
> 95, The Language Speaks for Itself".  This paper will appear in the May
> Object Magazine.  In this paper we modeled money as a decimal type and
did
> inheritance directly via a generic.  I had suggested modeling money as a
> tagged type.  My co-authors very wisely vetoed that approach.  After
the>>
> 
> I can't see any reason for wanting to model money as a tagged type -- you
> lose literals, and you lose a lot of other useful semantics of decimal
> types, and you gain nothing  that I can see.


I think I can see a few possibilities: for example, what if you wanted to
be able to use multiple currencies easily? You can get literals reasonably
easily by the use of simple conversion functions. For example:

package Money is
   type General_Monetary_Amount is limited private;
   type US_Dollars is delta 0.01 digits 12;
   type Lire is delta 100 digits 14;
   ...
   function To_General(Amount: in US_Dollars) return
General_Monetary_Amount;
   function To_General(Amount: in Lire) return General_Monetary_Amount;
   ...
private
   ...
end;

and then a 'literal' can be constructed with something like

To_General(US_Dollars'(59.23))

This is slightly clumsy, of course, but not too bad.

If we had defined General_Monetary_Amount as tagged, we could extend it,
perhaps to provide a date (for aiding exchange calculations):

package Money.Dated is
   type Dated_Monetary_Amount is new General_Monetary_Amount;
   ...
private
   type Dated_Monetary_Amount is new General_Monetary_Amount with
      record
         Date: Calendar.Time;
      end record;
end;

And so on. Just thoughts (and it's gone midnight).

Nick.

   

Re: Tagged Types and Generics

[Robert I. Eachus]

In article <3.0.32.19970421225247.007129f4@mail.4dcomm.com> "Robert C. Leif, Ph.D." <rleif@RLEIF.COM> writes:

  > After the paper was submitted, I attempted to do my suggestion and
  > model money as a tagged type with the child libraries being the
  > different currencies.  If one makes the exchange rate a decimal
  > type, then currency conversion requires a decimal division of the
  > same field from two of the child library units.

   Let's deal with two separate problems separately.  You want to have
an abstract general currency type, then derive to create different
currencies.  So far so good.  But your abstract type will have
non-currency operations.  If you do it right though objects won't
contain fields other than the fixed point field.  I see creating a
generic that takes a formal decimal type, a string or two, etc.  and
creates a new type derived from Currency with all these nice
properties.
 
   Next problem, you want to convert between two decimal types.  Once
you understand that this is a non-transitive relationship, you create
a generic conversion function in the Currencies package that needs to
do one of three things: 1) some very clever conversion code 2) use
floating point or 3) overflow under unexpected circumstances.  Lets
choose choice 1...


   package Currencies is

      type Currency is abstract tagged private;

      function Symbol(Value: in Currency) return String is abstract;

      function Name(Value: in Currency) return String is abstract;

      function "+"(L,R: Currency) return Currency is abstract;
      ...
      function To_String(Value: in Currency) return String;

   private

      type Currency is ...;

      function Integer_Part(Value: in Currency) return String is abstract;
      function Fractional_Part(Value: in Currency) return String is abstract;

   end Currencies;
 
   generic
      type Decimal is delta <> digits <>;
      Symbol: in String;
      Name: in String;
   package Currencies.Create is

      type Local is new Currencies.Currency with private;

      function "+" (L,R: Local) return Local;...

   private

      type Local is new Currencies.Currency with record
         Value: Decimal := 0.0;
      end record;

   end Currencies.Create;

   generic
      type From is new Currency;
      type To is new Currency;
      Multiplier: in String; -- i.e. "123.456789"
   function Conversion(Amount: in From) return To;

   function Conversion(Amount: in From) return To is
   begin
      return Integer'Value(Integer_Part(Amount)) * From'Value(Multiplier)
         + From'Value(Fractional_Part(Amount)) * From'Value(Multiplier);
   exception 
      when others => TBD;
   end Conversion;

   You might want to use a rational arithmetic package instead, or
some such.  But the real problem is that currency conversions will
change in how they are specified and computed a lot faster than your
software.  You really do need to accept arbitrarily long strings of
zeros--which I didn't do here--when a currency devalues rapidly.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Tagged Types and Generics

[Tom Moran]

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?