why access parameter in stream attributes to begin with, instead of in or in/out ?

why access parameter in stream attributes to begin with, instead of in or in/out ?

[Mehdi Saada]

Hi.

I wondered why in Ichibiah's design, in the beginning, stream have been made to work with access types/access parameters ?  I could have imagined that the attributes would work with a in/out stream parameter, and stream(blabla) would give an object of stream type.
I don't know if storing streams' access values for later use is common, one would just have to add .all when appropriate...

Thanks.

Re: why access parameter in stream attributes to begin with, instead of in or in/out ?

[Shark8]

On Monday, June 11, 2018 at 3:49:28 PM UTC-6, Mehdi Saada wrote:
> Hi.
> 
> I wondered why in Ichibiah's design, in the beginning, stream have been made to work with access types/access parameters ?
Hard to say; his design [Ada83] didn't have streams.

> I could have imagined that the attributes would work with a in/out stream parameter, and stream(blabla) would give an object of stream type.
> I don't know if storing streams' access values for later use is common, one would just have to add .all when appropriate...
Good questions, I want to say it's not common to pop access-type via streams, but maybe I'm just unadventurous.

Re: why access parameter in stream attributes to begin with, instead of in or in/out ?

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:cb1b3f8b-bf3b-4768-99af-5575a55cf682@googlegroups.com...
> On Monday, June 11, 2018 at 3:49:28 PM UTC-6, Mehdi Saada wrote:
>> Hi.
>>
>> I wondered why in Ichibiah's design, in the beginning, stream have been 
>> made to work with access types/access parameters ?
> Hard to say; his design [Ada83] didn't have streams.

Right, streams were an Ada 95 feature.

>> I could have imagined that the attributes would work with a in/out stream 
>> parameter, and stream(blabla) would give an object of stream type.
>> I don't know if storing streams' access values for later use is common, 
>> one would just have to add .all when appropriate...
> Good questions, I want to say it's not common to pop access-type via 
> streams, but maybe I'm just unadventurous.

Ada 83/95/2005 do not allow functions to have parameters that are out or in 
out. "access" was (mistakenly) thought to be a work-around for that. 
Streams, being an Ada 95 feature, used that work-around. It used it 
consistently, I suppose so that all of the stream attributes would work the 
same (it would be weird for Input and Read to work differently - remember, 
Input is a function and has to be one since the result in unconstrained).

                                          Randy.

Re: why access parameter in stream attributes to begin with, instead of in or in/out ?

[Mehdi Saada]

Oh... Understood. In the first draft/drafts, functions were in/out, that was forsaken for the sake of purity from side-effects, then for the sake of the said side-effects access parameters are added (don't know if dispatching on access parameters/results were added at the same moment), yet they waited one more version to put back in-out function parameters... Surely there are many reasons (probably) but it still seems funny.

Re: why access parameter in stream attributes to begin with, instead of in or in/out ?

[Dmitry A. Kazakov]

On 2018-06-12 08:28, Mehdi Saada wrote:
> Oh... Understood. In the first draft/drafts, functions were in/out, that was forsaken for the sake of purity from side-effects, then for the sake of the said side-effects access parameters are added (don't know if dispatching on access parameters/results were added at the same moment), yet they waited one more version to put back in-out function parameters... Surely there are many reasons (probably) but it still seems funny.

There was no clear understanding of the contracts back then. Absence of 
side effects is a behavioral contract #1. It is different from absence 
of effects on the parameters #2. One can have any combination of these 
two. The choice was to have functions with any side effects allowed but 
no effects on the parameters except the dedicated one = the result. It 
was a pragmatic choice because that time it was impossible to have 
contracts on the side effects. Now we have SPARK and profiles, it should 
be possible.

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