!standard 13.05.01(00)                                 03-12-05  AC95-00089/01
!class amendment 03-12-05
!status received no action 03-12-05
!status received 03-11-05
!subject Representation clause for nested records

!appendix

!topic Representation clause for nested records
!reference RM95-13.5.1, 13.6
!from Jeff Cousins 03-11-05
!keywords record representation clause
!discussion

Many programmers would like to be able to define representation clauses for
nested records.  Currently the type conversion between two representations
of the same record, as in 13.6, only appears to be possible for "flat"
records.

Would some sort of hierarchical representation clause, as in the following,
be possible?

package MY_REC_T_PKG is

  type NESTED_REC_T is record
    FIELD_1 : INTEGER;
    FIELD_2 : FLOAT;
  end record;

  type MY_REC_T is record
    HEADER : INTEGER;
    DATA   : NESTED_REC_T;
  end record;

  type REPRESENTED_REC_T is new MY_REC_T;
  for  REPRESENTED_REC_T use record;
    HEADER       at 0 range 0 .. 31;
    DATA.FIELD_1 at 4 range 0 .. 31;
    DATA.FIELD_2 at 8 range 0 .. 31;
  end record;

  procedure CONVERT (
   RAW_DATA       : in  REPRESENTED_REC_T;
   PROCESSED_DATA : out MY_REC_T);

end MY_REC_T_PKG;

package body MY_REC_T_PKG is

  procedure CONVERT (
   RAW_DATA       : in  REPRESENTED_REC_T;
   PROCESSED_DATA : out MY_REC_T) is
  begin
    PROCESSED_DATA := MY_REC_T (
                       RAW_DATA);
  end CONVERT;

end MY_REC_T_PKG;

****************************************************************

From: Nick Roberts
Sent: Tuesday, November 11, 2003  1:05 PM

>Would some sort of hierarchical representation clause, as in the following,
>be possible?

 From an implementor's point of view, I think the short answer is "No."

The problem is that this would require deep-seated changes to the
internals of an existing compiler (something along the lines of
introducing multiple internal types that correspond to one nominal
type). In many cases, it would also require the introduction of
scatter/gather record representations. I can see implementors being a
little bit unhappy about having to make this kind of change to their
compilers.

>package MY_REC_T_PKG is
>
>  type NESTED_REC_T is record
>    FIELD_1 : INTEGER;
>    FIELD_2 : FLOAT;
>  end record;
>
>  type MY_REC_T is record
>    HEADER : INTEGER;
>    DATA   : NESTED_REC_T;
>  end record;
>
>  type REPRESENTED_REC_T is new MY_REC_T;
>  for  REPRESENTED_REC_T use record;
>    HEADER       at 0 range 0 .. 31;
>    DATA.FIELD_1 at 4 range 0 .. 31;
>    DATA.FIELD_2 at 8 range 0 .. 31;
>  end record;
>
>  procedure CONVERT (
>   RAW_DATA       : in  REPRESENTED_REC_T;
>   PROCESSED_DATA : out MY_REC_T);
>
>end MY_REC_T_PKG;
>
>package body MY_REC_T_PKG is
>
>  procedure CONVERT (
>   RAW_DATA       : in  REPRESENTED_REC_T;
>   PROCESSED_DATA : out MY_REC_T) is
>  begin
>    PROCESSED_DATA := MY_REC_T (
>                       RAW_DATA);
>  end CONVERT;
>
>end MY_REC_T_PKG;
>
>

In this case, the obvious alternative is to declare REPRESENTED_REC_T as
a 'flat' new record type (not derived), with all the necessary fields,
and  the requisite representation clause. The CONVERT procedure must
then assign the fields explicitly. Ugly, but it works, as they say.

package MY_REC_T_PKG is

  type NESTED_REC_T is record
    FIELD_1 : INTEGER;
    FIELD_2 : FLOAT;
  end record;

  type MY_REC_T is record
    HEADER : INTEGER;
    DATA   : NESTED_REC_T;
  end record;

  type REPRESENTED_REC_T is record
    HEADER  : INTEGER;
    FIELD_1 : INTEGER;
    FIELD_2 : FLOAT;
  end record;

  for  REPRESENTED_REC_T use record;
    HEADER  at 0 range 0 .. 31;
    FIELD_1 at 4 range 0 .. 31;
    FIELD_2 at 8 range 0 .. 31;
  end record;

  procedure CONVERT (
   RAW_DATA       : in  REPRESENTED_REC_T;
   PROCESSED_DATA : out MY_REC_T);

end MY_REC_T_PKG;

package body MY_REC_T_PKG is

  procedure CONVERT (
   RAW_DATA       : in  REPRESENTED_REC_T;
   PROCESSED_DATA : out MY_REC_T) is
  begin
    PROCESSED_DATA.HEADER       := RAW_DATA.HEADER;
    PROCESSED_DATA.DATA.FIELD_1 := RAW_DATA.FIELD_1;
    PROCESSED_DATA.DATA.FIELD_2 := RAW_DATA.FIELD_2;
  end CONVERT;

end MY_REC_T_PKG;


I don't doubt you were perfectly aware of this alternative. It is so bad
as to be desperate?

****************************************************************

From: Jeff Cousins
Sent: Monday, November 17, 2003  10:21 AM

I've been mulling this over, and I appreciate that it would be hard to
implement as it's implicitly deriving types for the components that are also
records, but I think that is just the sort of laborious thing that a
compiler for a high level language should be doing, rather than the
programmers having to write conversion routines of the type that you suggest
- that is just what I was trying to avoid.
For many defence projects a major item of work is of the form 'take some
legacy interface with the raw data packed in this horrible way, then convert
it a nice structure using the built-in types, then you can perform the xyz
algorithm on it'.

****************************************************************