Hi Ken,

I have no insights into the history, but I can offer some
specification interpretation:

The specification of #content goes on to define: "Returns a collection
that contains the receiver’s past and future sequence values, in
order. The
size of the collection is the sum of the sizes of the past and future
sequence values."

WriteStream conforms to the protocols puttableStream and
collectionStream. A puttableStream "allows objects to be added to its
past sequence values", so in a way one could argue it does not need to
have any future sequence values that could be read (then it would be a
gettableStream). If you rewind the stream by setting the position
backwards, you effectively remove some past sequence values, so they
need no longer be part of the contents.

collectionStream basically says that the Stream operates on a
SequenceableCollection object and it is explicitly unspecified whether
#contents returns the underlying collection or another one of the same
species, in Squeak terms.

Unfortunately things get blurry with the specification of #position: amount.
"If the number of sequence values in the receiver's past sequence
values is greater than amount, move objects in sequence from the back
of the receiver's past sequence values to the front of the receiver's
future sequence values until the number of sequence values in the
receiver's past sequence values is equal to amount."
So to make this fit we would again have to assume that a WriteStream
does not have future sequence values and therefore pretends to forget
what has been rewound.

If I understand this correctly, then it would be a contradiction to
the #contents implementation if it were possible to set the position
of a WriteStream forward again and thereby restore some previously
rewound values. Does this work in Squeak?

Kind regards,
Jakob

Am Di., 29. Juni 2021 um 22:14 Uhr schrieb Ron Teitelbaum <ron at usmedrec.com>:
>
> Hi Ken,
>
> I think the issue is that when you change the position of the stream you are really telling it to limit the write stream to that position.  It's a way to hit backspace and start over.
>
> so if I say position is 2 then I get the first two elements only.
>
> ws := WriteStream on: #[].
> ws nextPut: 65.
> ws nextPut: 80.
> ws nextPut: 50.
> ws contents printString. '#[65 80 50]'
> "limit to position 2"
> ws position: 2.
> ws contents printString.  '#[65 80]'
>
> "I can then write more from there."
>
> ws nextPut: 51.
> ws contents printString.  '#[65 80 51]'
>
> All the best,
>
> Ron Teitelbaum
>
> On Tue, Jun 29, 2021 at 3:10 PM <ken.dickey at whidbey.com> wrote:
>>
>> Greetings,
>>
>> Perhaps some one out there can help me understand some history.
>>
>> ANSI Smalltalk 5.9.1.2 indicates that #contents "Returns a collection
>> containing the complete contents of the stream."
>>
>> WriteStream>>contents does not do this.  ReadWriteStream>>contents does
>> do this.
>>
>> Why the difference?
>>
>> vvv===vvv
>> ws := WriteStream on: #[].
>> ws nextPut: 65.
>> ws nextPut: 80.
>> ws contents printString. '#[65 80]'
>> "Second result is expected to match 1st"
>> ws position: 1.
>> ws contents printString. '#[65]'
>> ^^^===^^^
>>
>> I am puzzled.  Must be some reason for this lost in the sands of time..
>>
>> Thanks for any help uncovering the history and rationale here,
>> -KenD
>>
>