So I've been messing around with the new Ada 2020 package Ada.Streams.Storage.Bounded/Unbounded; and if I'm understand it correctly it allows you to treat your program's memory like a stream without having to open file descriptors (which should make it faster?). That seems like a powerful abstraction to me and a great addition to the language.

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Streams; use Ada.Streams;
with Ada.Streams.Storage.Unbounded; use Ada.Streams.Storage.Unbounded;

procedure Test is
Test : String := "040b2cec765b4bbbdb29d83b6dcaf776";
Test_Stream : aliased Stream_Type;
begin
String'Write(Test_Stream'Access, Test);
for I in 1 .. Element_Count (Test_Stream) loop
declare
C : Character;
begin
Character'Read (Test_Stream'Access, C);
Put (C);
end;
end loop;
end Test;

I was wondering if we could find a better way to fill the stream other than writing the variables into it? Can anyone figure out a good way to just stream a variable's bytes directly?

Michael Hardeman <mhardeman25@gmail.com> writes:

> So I've been messing around with the new Ada 2020 package
> Ada.Streams.Storage.Bounded/Unbounded; and if I'm understand it
> correctly it allows you to treat your program's memory like a stream
> without having to open file descriptors (which should make it
> faster?). That seems like a powerful abstraction to me and a great
> addition to the language.

This would be my version:

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Streams.Storage.Unbounded;

procedure Test is
Test : constant String := "040b2cec765b4bbbdb29d83b6dcaf776";
Test_Stream : aliased Ada.Streams.Storage.Unbounded.Stream_Type;
begin
String'Output (Test_Stream'Access, Test);
declare
S : constant String := String'Input (Test_Stream'Access);
begin
Put_Line (S);
end;
end Test;

'Output writes the discriminants of the object, if any, then the object;
'Input uses them to reconstruct the object, so in this case that means
the bounds, and hence the length.

> I was wondering if we could find a better way to fill the stream other
> than writing the variables into it? Can anyone figure out a good way
> to just stream a variable's bytes directly?

This *is* the way to just stream the variable's bytes directly. What
sort of syntax were you hoping for?

On Monday, May 17, 2021 at 3:14:43 PM UTC-4, Simon Wright wrote:
>
> 'Output writes the discriminants of the object, if any, then the object;
> 'Input uses them to reconstruct the object, so in this case that means
> the bounds, and hence the length.
> > I was wondering if we could find a better way to fill the stream other
> > than writing the variables into it? Can anyone figure out a good way
> > to just stream a variable's bytes directly?
> This *is* the way to just stream the variable's bytes directly. What
> sort of syntax were you hoping for?

I was kind of hoping there would be an interface like Ada.Text_IO.Text_Streams, where you could just directly stream from the variable's address or access without having to write the variable into the stream first. I'm not sure, but the writing part seems a bit like an extra step.

This would be my version:
>
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Streams.Storage.Unbounded;
>
> procedure Test is
> Test : constant String := "040b2cec765b4bbbdb29d83b6dcaf776";
> Test_Stream : aliased Ada.Streams.Storage.Unbounded.Stream_Type;
> begin
> String'Output (Test_Stream'Access, Test);
> declare
> S : constant String := String'Input (Test_Stream'Access);
> begin
> Put_Line (S);
> end;
> end Test;

I was kind of trying to show you could move through the stream like a parser instead of just consuming the whole thing. i.e. like if you wanted to parse the hex into an array of Unsigned_32 or Unsigned_64 for some algorithm.

On 2021-05-17 21:14, Simon Wright wrote:
> Michael Hardeman <mhardeman25@gmail.com> writes:
>
>> So I've been messing around with the new Ada 2020 package
>> Ada.Streams.Storage.Bounded/Unbounded; and if I'm understand it
>> correctly it allows you to treat your program's memory like a stream
>> without having to open file descriptors (which should make it
>> faster?). That seems like a powerful abstraction to me and a great
>> addition to the language.

1. It was always possible, since Ada 95, actually. So it is not that
great addition.

2. The package as described is not a replacement for I/O, because it
lacks blocking/synchronization and because it does not work between
processes. E.g. at the end of the stream Read must rather block for an
incoming Write. Both are quite possible to implement though.

A great addition would be properly tagged protected objects and tasks. A
blocking stream cannot support timed entry call syntax like this:

select
S := String'Input (Pipe'Access); -- This is not Ada!
or delay 1.0;
raise Timed_Out;
end select;

And note another problem. Entries do not work with indefinite objects.
You cannot return String from an entry call.

And yet another problem, you cannot use returned objects in many places,
like in an entry call above.

>> I was wondering if we could find a better way to fill the stream other
>> than writing the variables into it? Can anyone figure out a good way
>> to just stream a variable's bytes directly?

Allocators, of course. I am using both allocators and memory-mapped
streams (though of a greater variety, e.g. for blocked exchange,
encryption, interporcess communication).

> This *is* the way to just stream the variable's bytes directly. What
> sort of syntax were you hoping for?

Both allocators and streams require explicit specification of the type.
Clearly, that is a way around multiple dispatch, but it is way too
heavy. Access to stream is no more necessary in 'Input. It was not
necessary when it was introduced in Ada 95. The Rosen's trick allows
circumvent in- parameter modes, when necessary.

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

On Monday, May 17, 2021 at 4:20:14 PM UTC-4, Dmitry A. Kazakov wrote:
> On 2021-05-17 21:14, Simon Wright wrote:
> > Michael Hardeman <mhard...@gmail.com> writes:
> >
> >> So I've been messing around with the new Ada 2020 package
> >> Ada.Streams.Storage.Bounded/Unbounded; and if I'm understand it
> >> correctly it allows you to treat your program's memory like a stream
> >> without having to open file descriptors (which should make it
> >> faster?). That seems like a powerful abstraction to me and a great
> >> addition to the language.
> 1. It was always possible, since Ada 95, actually. So it is not that
> great addition.
>
> 2. The package as described is not a replacement for I/O, because it
> lacks blocking/synchronization and because it does not work between
> processes. E.g. at the end of the stream Read must rather block for an
> incoming Write. Both are quite possible to implement though.
>
> A great addition would be properly tagged protected objects and tasks. A
> blocking stream cannot support timed entry call syntax like this:
>
> select
> S := String'Input (Pipe'Access); -- This is not Ada!
> or delay 1.0;
> raise Timed_Out;
> end select;
>
> And note another problem. Entries do not work with indefinite objects.
> You cannot return String from an entry call.
>
> And yet another problem, you cannot use returned objects in many places,
> like in an entry call above.
> >> I was wondering if we could find a better way to fill the stream other
> >> than writing the variables into it? Can anyone figure out a good way
> >> to just stream a variable's bytes directly?
> Allocators, of course. I am using both allocators and memory-mapped
> streams (though of a greater variety, e.g. for blocked exchange,
> encryption, interporcess communication).
> > This *is* the way to just stream the variable's bytes directly. What
> > sort of syntax were you hoping for?
> Both allocators and streams require explicit specification of the type.
> Clearly, that is a way around multiple dispatch, but it is way too
> heavy. Access to stream is no more necessary in 'Input. It was not
> necessary when it was introduced in Ada 95. The Rosen's trick allows
> circumvent in- parameter modes, when necessary.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Hey Dmitry,

> Allocators, of course. I am using both allocators and memory-mapped
> streams (though of a greater variety, e.g. for blocked exchange,
> encryption, interporcess communication).

Could you show me an example of how I could do this with allocators?

Le 17/05/2021 à 22:20, Dmitry A. Kazakov a écrit :
> On 2021-05-17 21:14, Simon Wright wrote:
>> Michael Hardeman <mhardeman25@gmail.com> writes:
>>
>>> So I've been messing around with the new Ada 2020 package
>>> Ada.Streams.Storage.Bounded/Unbounded; and if I'm understand it
>>> correctly it allows you to treat your program's memory like a stream
>>> without having to open file descriptors (which should make it
>>> faster?). That seems like a powerful abstraction to me and a great
>>> addition to the language.
>
> 1. It was always possible, since Ada 95, actually. So it is not that
> great addition.
For example, you can get Storage_Stream from Adalog's components page:
https://www.adalog.fr/en/components.html#Storage_Stream

[...]
> And note another problem. Entries do not work with indefinite objects.
> You cannot return String from an entry call.
True, but you can return an indefinite holder containing the string.

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

On 5/18/21 11:08 AM, J-P. Rosen wrote:
>
> True, but you can return an indefinite holder containing the string.

Usually called Unbounded_String.

--
Jeff Carter
"Damn it, Jim, I'm an actor, not a doctor."
124

To emulate a stream on "any" locatoion
https://github.com/persan/a-stream-tools
/P

On 17/05/2021 22:48, Michael Hardeman wrote:
> On Monday, May 17, 2021 at 4:20:14 PM UTC-4, Dmitry A. Kazakov wrote:
>> On 2021-05-17 21:14, Simon Wright wrote:
>>> Michael Hardeman <mhard...@gmail.com> writes:
>>>
>>>> So I've been messing around with the new Ada 2020 package
>>>> Ada.Streams.Storage.Bounded/Unbounded; and if I'm understand it
>>>> correctly it allows you to treat your program's memory like a stream
>>>> without having to open file descriptors (which should make it
>>>> faster?). That seems like a powerful abstraction to me and a great
>>>> addition to the language.
>> 1. It was always possible, since Ada 95, actually. So it is not that
>> great addition.
>>
>> 2. The package as described is not a replacement for I/O, because it
>> lacks blocking/synchronization and because it does not work between
>> processes. E.g. at the end of the stream Read must rather block for an
>> incoming Write. Both are quite possible to implement though.
>>
>> A great addition would be properly tagged protected objects and tasks. A
>> blocking stream cannot support timed entry call syntax like this:
>>
>> select
>> S := String'Input (Pipe'Access); -- This is not Ada!
>> or delay 1.0;
>> raise Timed_Out;
>> end select;
>>
>> And note another problem. Entries do not work with indefinite objects.
>> You cannot return String from an entry call.
>>
>> And yet another problem, you cannot use returned objects in many places,
>> like in an entry call above.
>>>> I was wondering if we could find a better way to fill the stream other
>>>> than writing the variables into it? Can anyone figure out a good way
>>>> to just stream a variable's bytes directly?
>> Allocators, of course. I am using both allocators and memory-mapped
>> streams (though of a greater variety, e.g. for blocked exchange,
>> encryption, interporcess communication).
>>> This *is* the way to just stream the variable's bytes directly. What
>>> sort of syntax were you hoping for?
>> Both allocators and streams require explicit specification of the type.
>> Clearly, that is a way around multiple dispatch, but it is way too
>> heavy. Access to stream is no more necessary in 'Input. It was not
>> necessary when it was introduced in Ada 95. The Rosen's trick allows
>> circumvent in- parameter modes, when necessary.
>>
>> --
>> Regards,
>> Dmitry A. Kazakov
>> http://www.dmitry-kazakov.de
>
> Hey Dmitry,
>
>> Allocators, of course. I am using both allocators and memory-mapped
>> streams (though of a greater variety, e.g. for blocked exchange,
>> encryption, interporcess communication).
>
> Could you show me an example of how I could do this with allocators?
>

On Monday, May 17, 2021 at 12:44:05 PM UTC-6, mhard wrote:
Here's an implementation of a string-as-a-stream: https://stackoverflow.com/a/66971547/608963
It was used in a JSON parser, so you certainly can use it for parsing... actually the idea here: to have a single production-method shared by stream and string [and file] is really quite nice maintenance-wise, even if you have to jump through a few hoops (like constructing this stream-string type) in order to obtain it.

Michael Hardeman <mhardeman25@gmail.com> writes:

> I was kind of hoping there would be an interface like
> Ada.Text_IO.Text_Streams, where you could just directly stream from
> the variable's address or access without having to write the variable
> into the stream first. I'm not sure, but the writing part seems a bit
> like an extra step.
[...]
> I was kind of trying to show you could move through the stream like a
> parser instead of just consuming the whole thing. i.e. like if you
> wanted to parse the hex into an array of Unsigned_32 or Unsigned_64
> for some algorithm.

I don't understand the scenario.

Source >> Stream >> Destination

If Source and Destination are in the same process, there's no need to
involve streams at all.

If Source and Destination are separated - different processes on the
same computer, different computers (possibly with different endianness),
different times - we have to agree on a protocol as to what's sent over
the stream. For a String Z, perhaps the first 4 bytes are the
little-endian Z'First, the next are Z'Last, then the actual bytes of Z.

That's what streams are for (and that's what String'Output does).

Once you have the stream, you can go through it in any way you need to;
you must know what to expect so as to make sense of it. In your example,
you have to know that the bytes in the stream are hex characters.

==========

As to creating the stream: I suppose there could be something like
'Image, where the attribute could originally only be applied to a type:
you used to have to say

Integer'Image (An_Integer)

whereas now you can say just

An_Integer'Image

so as well as the current ARM 13.13.2(4), for subtype S of type T

procedure S'Write(
Stream : not null access Ada.Streams.Root_Stream_Type'Class;
Item : in T)

one could have for an object O

procedure O'Write(
Stream : not null access Ada.Streams.Root_Stream_Type'Class)

but we don't, not even in Ada 202x.

On 2021-05-18 22:39, Simon Wright wrote:
> Michael Hardeman <mhardeman25@gmail.com> writes:
>
>> I was kind of hoping there would be an interface like
>> Ada.Text_IO.Text_Streams, where you could just directly stream from
>> the variable's address or access without having to write the variable
>> into the stream first. I'm not sure, but the writing part seems a bit
>> like an extra step.
> [...]
>> I was kind of trying to show you could move through the stream like a
>> parser instead of just consuming the whole thing. i.e. like if you
>> wanted to parse the hex into an array of Unsigned_32 or Unsigned_64
>> for some algorithm.
>
> I don't understand the scenario.
>
> Source >> Stream >> Destination
>
> If Source and Destination are in the same process, there's no need to
> involve streams at all.

The picture actually is:

Producer -> Output stream = Input Stream -> Consumer

The producer could be a code generator, the consumer could be a parser.

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

Le 18/05/2021 à 22:39, Simon Wright a écrit :
> so as well as the current ARM 13.13.2(4), for subtype S of type T
>
> procedure S'Write(
> Stream : not null access Ada.Streams.Root_Stream_Type'Class;
> Item : in T)
>
> one could have for an object O
>
> procedure O'Write(
> Stream : not null access Ada.Streams.Root_Stream_Type'Class)
>
> but we don't, not even in Ada 202x.
For what benefit? Saving a few keystrokes?

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

Den 2021-05-19 kl. 09:17, skrev J-P. Rosen:
> Le 18/05/2021 à 22:39, Simon Wright a écrit :
>> so as well as the current ARM 13.13.2(4), for subtype S of type T
>>
>>     procedure S'Write(
>>        Stream : not null access Ada.Streams.Root_Stream_Type'Class;
>>        Item : in T)
>>
>> one could have for an object O
>>
>>     procedure O'Write(
>>        Stream : not null access Ada.Streams.Root_Stream_Type'Class)
>>
>> but we don't, not even in Ada 202x.
> For what benefit? Saving a few keystrokes?
>

The Integer'Image(An_Integer) changed to An_Integer'Image

the Verb(Object, Parameter) changed to Object.Verb(Parameter)

It does not have to save keystrokes, but it has to be more readable.
More readable is of course in the eye of the beholder.

package Coded_Values is

type WCS_Next_Location_Type_Type is (
Reject_Position,
Selection_Point,
Transfer_Unit);

end Coded_Values;

with Coded_Values;
with Text_Io;

package Test is

Next_Location : Coded_Values.WCS_Next_Location_Type_Type :=
Coded_Values.Selection_Point;

Given the above I do prefer

Text_IO.Put_Line ("Next is " & Next_Location'Image);

over

Text_IO.Put_Line ("Next is " &
Coded_Values.WCS_Next_Location_Type_Type'Image(Next_Location));

or when a use clause is in effect
Text_IO.Put_Line ("Next is " &
WCS_Next_Location_Type_Type'Image(Next_Location));

even with a use clause I prefer the 'image on the variable.
In my eyes

Text_IO.Put_Line ("Next is " & Next_Location'Image);

Is the better and more readable choice.

That is likely the case of the analog stream discussion above.

Syntax matter. If Ada is to grow it has to have a pleasant syntax,
that is not perceived as clumsy or overly wordy.

--
Björn

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 18/05/2021 à 22:39, Simon Wright a écrit :
>> so as well as the current ARM 13.13.2(4), for subtype S of type T
>> procedure S'Write(
>> Stream : not null access Ada.Streams.Root_Stream_Type'Class;
>> Item : in T)
>> one could have for an object O
>> procedure O'Write(
>> Stream : not null access Ada.Streams.Root_Stream_Type'Class)
>> but we don't, not even in Ada 202x.
> For what benefit? Saving a few keystrokes?

I was going to remark on the unlikelihood of ARG's accepting this
keystroke-saving change unless there was evidence of massive demand. In
the case of 'Image, there was the popularity of AdaCore's 'Img
extension.

Le 19/05/2021 à 10:26, Björn Lundin a écrit :
> Given the above I do prefer
>
>
> Text_IO.Put_Line ("Next is " & Next_Location'Image);
>
> over
>
> Text_IO.Put_Line ("Next is " &
> Coded_Values.WCS_Next_Location_Type_Type'Image(Next_Location));

Interesting example. When I define a type that I want to be able to
print, I define also (in the same place) an instantiation of
Integer_IO/Enumeration_IO, and I would write:
Put ("Next is "); Put (Next_Location); New_Line;

'Image was not intended for regular IO.

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

On 2021-05-19 21:25, J-P. Rosen wrote:
> Le 19/05/2021 à 10:26, Björn Lundin a écrit :
>> Given the above I do prefer
>>
>>
>> Text_IO.Put_Line ("Next is " & Next_Location'Image);
>>
>> over
>>
>> Text_IO.Put_Line ("Next is " &
>> Coded_Values.WCS_Next_Location_Type_Type'Image(Next_Location));
>
> Interesting example. When I define a type that I want to be able to
> print, I define also (in the same place) an instantiation of
> Integer_IO/Enumeration_IO, and I would write:
>    Put ("Next is "); Put (Next_Location); New_Line;
>
> 'Image was not intended for regular IO.

Maybe it was so in 1983. These days immediate I/O is impractical. Most
of use cases is about formatting strings and very rarely writing the
result into some file, usually stream. So 'Image is far more frequently
used than Integer_IO, Enumeration_IO etc. I did not use any of that for
decades. A programmer would not even care about them, because he will
not suddenly change the programming technique universally used with GUI
widgets, streams, database interfaces, for some obscure generic packages
when Text_IO gets involved.

So let's modify the example to:

Dialog.Message.Set_Text ("Next is " &
Coded_Values.WCS_Next_Location_Type_Type'Image(Next_Location));

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

Den 2021-05-19 kl. 21:25, skrev J-P. Rosen:
> Le 19/05/2021 à 10:26, Björn Lundin a écrit :
>> Given the above I do prefer
>>
>>
>> Text_IO.Put_Line ("Next is " & Next_Location'Image);
>>
>> over
>>
>> Text_IO.Put_Line ("Next is " &
>> Coded_Values.WCS_Next_Location_Type_Type'Image(Next_Location));
>
> Interesting example. When I define a type that I want to be able to
> print, I define also (in the same place) an instantiation of
> Integer_IO/Enumeration_IO, and I would write:
>    Put ("Next is "); Put (Next_Location); New_Line;
>
> 'Image was not intended for regular IO.
>

If a function/procedure is public, users will use them.
And very likely in ways 'not intended',
So there should be a clear statement in the RM making it clear
that using 'Image is not for regular IO.

We use tons of it for writing to log files
This is why I want 'image for record types.
It would save me from writing To_String functions dumping record values
into the log. I think it made it into 202x but I am not sure.

And reasoning 'when I define a type I want to print...' does
not really appeal to me. I'd like the language to provide a way to
create a string version of my variables - basically any of them -
for log file use. When I define a type I am not always thinking if this
may or may not will be logged in the future, by someone else.
This leads to all types must define a Image/To_String function.

Why? Whats the point? What is the gain?

For records with nested lists I can see challenges,
but for scalar values? Floats? Fixed?

Why not have an easy-to-use AND readable solution?

--
Björn

On 2021-05-19 23:18, Björn Lundin wrote:
> Den 2021-05-19 kl. 21:25, skrev J-P. Rosen:
>> ....
>> 'Image was not intended for regular IO.
>>
>
> If a function/procedure is public, users will use them.

I agree, and I use 'Image a lot.

> And very likely in ways 'not intended',
> So there should be a clear statement in the RM making it clear
> that using 'Image is not for regular IO.

What could the RM say, as motivation? Your karma will decrease 5 points
every time you use 'Image for regular IO? Or every such use brings a
1/10000 chance of aborting the program or producing wrong results? :-)

> We use tons of it for writing to log files
> This is why I want 'image for record types.
> It would save me from writing To_String functions dumping record values
> into the log. I think it made it into 202x but I am not sure.

It is in the 202x proposal, RM 4.10 (32/5). See
http://www.ada-auth.org/standards/2xaarm/html/AA-4-10.html.

Le 20/05/2021 à 07:38, Niklas Holsti a écrit :
> What could the RM say, as motivation? Your karma will decrease 5 points
> every time you use 'Image for regular IO? Or every such use brings a
> 1/10000 chance of aborting the program or producing wrong results? :-)
The concern I have with 'Image is that it provides no formatting.
Also for file IO, Put(I) (from Integer_IO) is better than
Put(Integer'Image(I)), because the former will never break the value on
two lines, while the latter can if the line length is bounded, making
the value impossible to read later. Of course, uses other than file IO
do not have this constraint.

The concern I have with Obj'Image is that there is no clean model of
what it is. All other attributes are properly defined as predefined
functions with a profile, they can be used to instantiate generics, etc.

"X'Image denotes the result of calling function S'Image with Arg being
X, where S is the nominal subtype of X."

So, it's a special notation, like a kind of macro, with no proper
definition. This hurts my purist's state of mind...

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

"J-P. Rosen" <rosen@adalog.fr> wrote in message
news:s850rr$mvm$1@dont-email.me...
....
> "X'Image denotes the result of calling function S'Image with Arg being X,
> where S is the nominal subtype of X."
>
> So, it's a special notation, like a kind of macro, with no proper
> definition. This hurts my purist's state of mind...

Naw, it's an attribute, just like 'Pos and 'First(N), neither of which
correspond to anything you can write. Saying that attributes are subprograms
(outside of the cases where redefinition is allowed, like 'Read) simply buys
a vast amount of special-case work with virtually no benefit to the user.
(In Janus/Ada, at least, we have to fake treating these things as functions,
as we could not afford [back in the day, of course] the space to materialize
all of these little-used functions. [Float types have some 20-odd of
them!]).

If someone has to pay a price, it might as well be the language standard and
not every implementer (and the users that actually try to use these things
as functions and run into bugs in stuff no one ever tries).

Water under the dam in any case, since no one has any reason to change any
of this.

Randy.