Ada.Storage_IO: applied example?

Ada.Storage_IO: applied example?

[Yannick Duchêne (Hibou57)]

Hi all the people,


I'm seeking for a tiny use case showing `Ada.Storage_IO` in action. I also  
believe the topic is worth for many people, beginners or not, as this is  
the kind of stuff so typical of Ada. I always liked the clean distinction  
Ada makes between streams and files. Looking for some reminder about it in  
the RM, I just noticed this `Ada.Storage_IO` I've never noticed before.,  
but feel surprised the buffer always contains a single element; thus the  
question. The RM makes a reference from there to `Ada.Direct_IO`, but the  
latter does not reciprocally mention the former.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada.Storage_IO: applied example?

[Dmitry A. Kazakov]

On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:

> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.

It looks useless at first glance. The buffer size is fixed and
implementation defined(!). Why would anybody use that rather than plain
array?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Storage_IO: applied example?

[Yannick Duchêne (Hibou57)]

Le Tue, 23 Oct 2012 22:28:34 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duchêne (Hibou57) wrote:
>
>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
>
> It looks useless at first glance.
Yes, indeed, it looks, lol. That's precisely the reason why I opened this  
topic. I would hardly believe something that usefulness belongs to the  
standard packages, so I guess I am missing something, and would like to  
learn what it is. Is this a kind of holder container?

> The buffer size is fixed and implementation defined(!).
It's implementation defined, but not “randomly”: the size correspond to  
the count of storage elements (it self, implementation defined) required  
to store an instance of the element type which is the parameter of the  
generic package. That's implementation defined, but predictable.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada.Storage_IO: applied example?

[Adam Beneschan]

On Tuesday, October 23, 2012 1:57:02 PM UTC-7, Hibou57 (Yannick Duchêne) wrote:
> Le Tue, 23 Oct 2012 22:28:34 +0200, Dmitry A. Kazakov  

> >> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
> > It looks useless at first glance.
> 
> Yes, indeed, it looks, lol. That's precisely the reason why I opened this  
> topic. I would hardly believe something that usefulness belongs to the  
> standard packages, so I guess I am missing something, and would like to  
> learn what it is. Is this a kind of holder container?
> 
> > The buffer size is fixed and implementation defined(!).
> 
> It's implementation defined, but not “randomly”: the size correspond to  
> the count of storage elements (it self, implementation defined) required  
> to store an instance of the element type which is the parameter of the  
> generic package. That's implementation defined, but predictable.

Looking at the AARM, it appears that the main reason this might be useful is you've defined a record type that contains a hidden pointer (i.e. a pointer that the Ada implementation sets up, not a subcomponent of an access type).  In that case, the buffer contains the "flattened" version of the data.  E.g.

   type Rec is record
     S : String (1 .. Name_Size);
     ... other components
   end record;

where Name_Size is non-static object (i.e. the value can't be determined at compile time).  Some implementations (but not GNAT, I believe) would store S as a pointer, rather than fool around with Rec objects whose size isn't known at compile time, and possibly components whose location in the record isn't known at compile time.  In this case, you couldn't rely on Rec'Size (or Rec'Size / System.Storage_Unit) to be large enough to contain all the data; I think that's the kind of case where the language designers thought this would be useful, because you could write code that would work with any Ada implementation.  Still, you should be able to accomplish the same thing using the stream features of Ada, and I think that would be preferable.

                           -- Adam

Re: Ada.Storage_IO: applied example?

[Jeffrey Carter]

On 10/23/2012 01:28 PM, Dmitry A. Kazakov wrote:
> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:
>
>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
>
> It looks useless at first glance. The buffer size is fixed and
> implementation defined(!). Why would anybody use that rather than plain
> array?

The buffer is the correct size that corresponds to an object of Element_Type. 
Much easier than figuring that out oneself.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: Ada.Storage_IO: applied example?

[Dmitry A. Kazakov]

On Tue, 23 Oct 2012 14:02:43 -0700, Jeffrey Carter wrote:

> On 10/23/2012 01:28 PM, Dmitry A. Kazakov wrote:
>> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:
>>
>>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
>>
>> It looks useless at first glance. The buffer size is fixed and
>> implementation defined(!). Why would anybody use that rather than plain
>> array?
> 
> The buffer is the correct size that corresponds to an object of Element_Type. 
> Much easier than figuring that out oneself.

Less than useless, as the name (I/O) gives a (false) impression that one
could read/write more than just one item into the thing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Storage_IO: applied example?

[J-P. Rosen]

Le 23/10/2012 22:28, Dmitry A. Kazakov a �crit :
> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:
> 
>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
> 
> It looks useless at first glance. The buffer size is fixed and
> implementation defined(!). Why would anybody use that rather than plain
> array?
> 
Imagine you want to implement a binary IO package. On one side you have
high level data type, on the other side system files that are just
blocks of bytes. Storage_IO allows you to bridge this gap (at least
that's my understanding).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada.Storage_IO: applied example?

[Dmitry A. Kazakov]

On Wed, 24 Oct 2012 07:03:43 +0200, J-P. Rosen wrote:

> Le 23/10/2012 22:28, Dmitry A. Kazakov a �crit :
>> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:
>> 
>>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
>> 
>> It looks useless at first glance. The buffer size is fixed and
>> implementation defined(!). Why would anybody use that rather than plain
>> array?
>> 
> Imagine you want to implement a binary IO package. On one side you have
> high level data type, on the other side system files that are just
> blocks of bytes. Storage_IO allows you to bridge this gap (at least
> that's my understanding).

In that case the package should rather define conversions to and from
Storage_Array, better as in-place operations with a position to get/put
data at. Furthermore the generic parameter should have been declared as:

   type Element_Type (<>) is private.

And, of course, implementation-defined I/O is a bad idea anyway in modern
times of interoperability. (This also applies to Direct_IO and
Sequential_IO, which are remnants of late 70's.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Storage_IO: applied example?

[AdaMagica]

See AARM A.9(1.a):
Reason: This package exists to allow the portable construction of user-defined direct-access-oriented input-output packages. The Write procedure writes a value of type Element_Type into a Storage_Array of size Buffer_Size, flattening out any implicit levels of indirection used in the representation of the type. The Read procedure reads a value of type Element_Type from the buffer, reconstructing any implicit levels of indirection used in the representation of the type. It also properly initializes any type tags that appear within the value, presuming that the buffer was written by a different program and that tag values for the “same” type might vary from one executable to another.

On Wednesday, October 24, 2012 9:34:32 AM UTC+2, Dmitry A. Kazakov wrote:
> data at. Furthermore the generic parameter should have been declared as:
>    type Element_Type (<>) is private.

See A.9(10.a):
Reason: As with Direct_IO, the Element_Type formal of Storage_IO does not have an unknown_discriminant_part so that there is a well-defined upper bound on the size of the buffer needed to hold the content of an object of the formal subtype (i.e. Buffer_Size). If there are no implicit levels of indirection, Buffer_Size will typically equal:
   (Element_Type'Size + System.Storage_Unit - 1) / System.Storage_Unit

Re: Ada.Storage_IO: applied example?

[Dmitry A. Kazakov]

On Wed, 24 Oct 2012 02:49:02 -0700 (PDT), AdaMagica wrote:

> See AARM A.9(1.a):
> Reason: This package exists to allow the portable construction of
> user-defined direct-access-oriented input-output packages.

   portable construction of X /= construction of portable X

The package cannot be used to write files in a way that an application
compiled by one compiler X1 under OS Y1 could write a file readable for
compiler X2 under OS Y2.

In order to be portable they should have defined the exact representation
of the object in the file. Yes, nobody would do that, but then they should
not include useless packages into the standard either.

> On Wednesday, October 24, 2012 9:34:32 AM UTC+2, Dmitry A. Kazakov wrote:
>> data at. Furthermore the generic parameter should have been declared as:
>>    type Element_Type (<>) is private.
> 
> See A.9(10.a):
> Reason: As with Direct_IO, the Element_Type formal of Storage_IO does not
> have an unknown_discriminant_part so that there is a well-defined upper
> bound on the size of the buffer needed to hold the content of an object of
> the formal subtype (i.e. Buffer_Size).

The reason why Direct_IO must have an upper bound is to allow accessing
records randomly without an excessive (in 70's it was excessive) overhead
of indexing them. This simply does not apply to Storage_IO, which has just
one "record."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Storage_IO: applied example?

[Yannick Duchêne (Hibou57)]

Le Wed, 24 Oct 2012 12:28:00 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Wed, 24 Oct 2012 02:49:02 -0700 (PDT), AdaMagica wrote:
>
>> See AARM A.9(1.a):
>> Reason: This package exists to allow the portable construction of
>> user-defined direct-access-oriented input-output packages.
>
>    portable construction of X /= construction of portable X
>
> The package cannot be used to write files in a way that an application
> compiled by one compiler X1 under OS Y1 could write a file readable for
> compiler X2 under OS Y2.
>
> In order to be portable they should have defined the exact representation
> of the object in the file. Yes, nobody would do that, but then they  
> should
> not include useless packages into the standard either.

What about private persistent storage?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada.Storage_IO: applied example?

[Dmitry A. Kazakov]

On Wed, 24 Oct 2012 13:51:21 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Wed, 24 Oct 2012 12:28:00 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
> 
>> On Wed, 24 Oct 2012 02:49:02 -0700 (PDT), AdaMagica wrote:
>>
>>> See AARM A.9(1.a):
>>> Reason: This package exists to allow the portable construction of
>>> user-defined direct-access-oriented input-output packages.
>>
>>    portable construction of X /= construction of portable X
>>
>> The package cannot be used to write files in a way that an application
>> compiled by one compiler X1 under OS Y1 could write a file readable for
>> compiler X2 under OS Y2.
>>
>> In order to be portable they should have defined the exact representation
>> of the object in the file. Yes, nobody would do that, but then they  
>> should not include useless packages into the standard either.
> 
> What about private persistent storage?

   X1 = X2 and Y1 = Y2

What are chances of having this? And what are chances that a user would
mistakenly use the package when X1 /= X2 or Y1 /= Y2?

Specifically to persistent storage, you would need to be able to debug it,
reinterpret using some independent tools, have redundancy and additional
checks on top, be able to store indefinite objects, be independent on the
medium etc. A *generic* package parametrized by a private type with no
representation defined is a non-starter.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Storage_IO: applied example?

[Georg Bauhaus]

On 24.10.12 13:51, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 24 Oct 2012 12:28:00 +0200, Dmitry A. Kazakov
> <mailbox@dmitry-kazakov.de> a écrit:
> 
>> On Wed, 24 Oct 2012 02:49:02 -0700 (PDT), AdaMagica wrote:
>>
>>> See AARM A.9(1.a):
>>> Reason: This package exists to allow the portable construction of
>>> user-defined direct-access-oriented input-output packages.
>>
>>    portable construction of X /= construction of portable X
>>
>> The package cannot be used to write files in a way that an application
>> compiled by one compiler X1 under OS Y1 could write a file readable for
>> compiler X2 under OS Y2.
>>
>> In order to be portable they should have defined the exact representation
>> of the object in the file. Yes, nobody would do that, but then they should
>> not include useless packages into the standard either.
> 
> What about private persistent storage?
> 

If traditional Ada I/O is good for your Ada program, you
can use Storage_IO in conventional algorithms this way. The
setup can employ static polymorphism that allows selecting
instances of Storage_IO or Direct_IO as needed.
Either at startup or later.

<rant>
The solution, using the egregious generic mechanisms of Ada,
will suffer from all the advantages of lack of an unused
tagged parameter.

The whole approach of stating requirements as generic formals
suffers from good opportunities for compilers to perform
optimization.

It suffers from the fact that stored internal program
data is not being stored in an ISO-approved form ready for
inspection by non-generic programs of an unrelated make
and purpose.

It also suffers from the problem that it still cannot make
the external world an Ada object, which could mollify the
previously argued flaw.

It suffers from lack of opportunities to control I/O of
octets algorithmically, thus preventing emulation of nice
per-program Storage_IO objects in DIY fashion.

It also suffers from not being a silver bullet.

But other than that ...</rant>

with Ada.Direct_IO;
with Ada.Storage_IO;
with Ada.Command_Line;  use Ada.Command_Line;

procedure Lookahead is
   use Ada;

   type Sentence (Length : Positive := 100) is record
      Text : Wide_String (1 .. 100);
   end record;

   subtype Name is Wide_String (1 .. 20);

   type Big is record   -- objects that will be processed
      First, Last : Name;
      Age : Natural;
      Motto : Sentence;
   end record;

   generic
      with procedure Store_Single_Item (Item : in Big);
      with procedure Fetch_Single_Item (Item : out Big);
   procedure Process_Records;

   procedure Process_Records is separate;
begin
   if Natural'Value (Argument(1)) = 0 then
      declare
         package Volatile is
            procedure Store (Item : in Big);
            procedure Fetch (Item : out Big);
         end Volatile;
         package body Volatile is
            package Undo_Buffer is new Storage_IO (Big);
            Storage : Undo_Buffer.Buffer_Type;
            procedure Fetch (Item : out Big) is
            begin
               Undo_Buffer.Read (Storage, Item);
            end Fetch;
            procedure Store (Item : in Big) is
            begin
               Undo_Buffer.Write (Storage, Item);
            end Store;
         end Volatile;
         procedure Run is new Process_Records
           (Store_Single_Item => Volatile.Store,
            Fetch_Single_Item => Volatile.Fetch);
      begin
         Run;
      end;
   else
      declare
         package Permanent is
            procedure Store (Item : in Big);
            procedure Fetch (Item : out Big);
         end Permanent;
         package body Permanent is
            package Undo_Buffer is new Direct_IO (Big);
            Storage : Undo_Buffer.File_Type;
            procedure Fetch (Item : out Big) is
            begin
               Undo_Buffer.Read (Storage, Item);
            end Fetch;
            procedure Store (Item : in Big) is
            begin
               Undo_Buffer.Write (Storage, Item);
            end Store;
            use Undo_Buffer;
         begin
            open (storage, Inout_File, "item.sto");
         end Permanent;
         procedure Run is new Process_Records
           (Store_Single_Item => Permanent.Store,
            Fetch_Single_Item => Permanent.Fetch);
      begin
         Run;
      end;
   end if;

end Lookahead;

separate (Lookahead)
procedure Process_Records is
   package Rec_IO is new Direct_IO (Big); use Rec_IO;
   Current: Big := (Age => Natural'Last, others => <>);
   input : File_Type;
   output : File_Type;
begin
   open (input, In_File, "records.all");
   open (output, Out_File, "records.flt");
   loop
      Store_Single_Item (Current);
      Read (input, current);
      -- ... filter based on pairs ...
         write (output, current);
   end loop;
end Process_Records;