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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,7722b78486dfd336
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!proxad.net!fr.ip.ndsoftware.net!216.196.110.149.MISMATCH!border2.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!transit.news.xs4all.nl!195.241.76.212.MISMATCH!tiscali!transit1.news.tiscali.nl!dreader2.news.tiscali.nl!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: Zero_Fill pragma, other proposition
References: <mailman.32.1090401708.416.comp.lang.ada@ada-france.org>
From: Ludovic Brenta <ludovic.brenta@insalien.org>
Date: Wed, 21 Jul 2004 12:09:37 +0200
Message-ID: <87vfghr7ry.fsf@insalien.org>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
Cancel-Lock: sha1:Fzh6Nqot5yiZhJV4N5+iHkLA45Q=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Tiscali bv
NNTP-Posting-Date: 21 Jul 2004 12:08:43 CEST
NNTP-Posting-Host: 83.134.237.146
X-Trace: 1090404523 dreader2.news.tiscali.nl 62386 83.134.237.146:32803
X-Complaints-To: abuse@tiscali.nl
Xref: g2news1.google.com comp.lang.ada:2312
Date: 2004-07-21T12:08:43+02:00
List-Id: <comp.lang.ada>

Lionel Draghi writes:
> | De: Jean-Pierre Rosen ...
> | OTOH, I suspect that very few types would need
> | that pragma (as you describe, a couple of types very strongly 
> | connected to hardware), so writing more fields is not really a
> | problem.
> In our case, it's a common problem : we have lots of messages with spare
> fields, and setting them to 0 for out going messages is a requirement.
> (On the other hand, even without this requirement, it would ease regression
> testing.
> Simple regression test tools based on diff raise false alarm because spare
> fields may be whatever on each run).
>
> So, our current policy is to explicitly state each spare. I don't feel
> confortable with this because the low level representation emerge in the
> definition.
> I don't want users to access the spare fields.
> I don't event want users to see the spare fields.
>
> What could be a good deal is to allows spare fields to appear in the
> representation clause.
>
> Kind of :
>
> type Message is record
>    Id   : Message_Id;
>    Data : Byte_Stream;
> end record;
>
> for Message use record
>    Id    at 0 range 0 .. 7;
>    Spare at 0 range 8 .. 15 := 0; --> ADDED
>    Data  at 0 range 16 .. 65;
> end record;
>
> This way, representation stuff don't emerge in the "user's" view,
> but spares are explicit in the "coder's" view.

Even though I like your proposal, I'm not sure that a new language
construct is required.  You can use encapsulation to prevent users
from seeing the spare fields, like this:

package P is
   type Message is record
      Id   : Message_ID;
      Data : Byte_Stream;
   end record;

   -- Primitive operations of Message go here
private
   type Representation is record
      Id    : Message_ID;
      Spare : Eight_Bits;
      Data  : Byte_Stream;
   end record;

   for Representation use record
      Id    at 0 range 0 .. 7;
      Spare at 0 range 8 .. 15;
      Data  at 0 range 16 .. 65;
   end record;
   
   function To_Rep (M : in Message) return Representation;
   function To_Message (R : in Representation) return Message;
end P;


package body P is
   function To_Rep (M : in Message) return Representation is
   begin
      return (Id => M.Id, Spare => 0, Data => R.Data);
   end To_Rep;

   function To_Message (R : in Representation) return Message is
   begin
      return (Id => R.Id, Data => R.Data);
   end To_Message;

   -- Primitive operations of Message convert to Representation whenever
   -- interfacing to hardware
end P;

I realise that your proposal reduces the amount of work required to
achieve this, but the current language does allow you to do what you
want.

-- 
Ludovic Brenta.