Re: Internal data representation

[barmar@think.COM (Barry Margolin)]

In article <8902081403.AA15437@ajpo.sei.cmu.edu> LEHMAN%ASD.SPAN@STAR.STANFORD.EDU (Richard A Lehman, DMSTB) writes:
>Bernard Badger of Harris states "I've been wondering why you 
>*want* to access the ``internal'' respresentation.
>
>Here at Johnson Space Center on the Space Station Program we
>have to access the ``internal'' representation of Ada types
>on many different tupes Heterogenous machines.  This is the only
>way we can provide a common transmission format to communicate
>amoung different type of ISAs.  

Why do you have to use the internal representation as the interchange
representation?  What's wrong with something like (excuse my syntax --
I'm not really an Ada programmer):

package COLORS is

  type COLOR is (RED, ORANGE, YELLOW, GREEN, BLUE, VIOLET); -- rainbow order
  REP: constant array(COLOR'FIRST..COLOR'LAST) of COLOR :=
    (BLUE, GREEN, ORANGE, RED, VIOLET, YELLOW); -- alphabetical order

  procedure WRITE (S: STREAM, C: COLOR) is
  begin
    for I in REP'FIRST..REP'LAST loop
      if REP(I) = C then
	INTEGER_IO.WRITE (S, I);
	exit;
      end if;
    end loop;
  end WRITE;

  function READ (S: STREAM) return COLOR is
  begin
    return REP(INTEGER_IO.READ (S));
  end READ;

end COLORS;

My impression is that the ability to specify the internal
representation is strictly to permit enumerated types to be used to
access data whose representation is defined by external forces.  For
instance, if an Ada structure were mapped over the memory used for a
network packet buffer, an enumeriated type could be used to read the
packet type field.  The internal representation clause allows you to
map Ada values to values defined by a standard protocol.

But if all you care about is communication between programs that you
have full control over, you can define an arbitrary representation, as
I did above (notice that the order of the elements in REP is different
from the order in the type definition, to emphasize the arbitrariness
of the representation).

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar