[Pharo-users] Stream >> <<

Herby Vojčík herby at mailbox.sk
Tue Sep 10 11:12:09 EDT 2019


On 10. 9. 2019 14:54, Richard O'Keefe wrote:
> I think it's fair to say that #<< *is* a bug.
> There does not seem to be any coherent description of what it means.
> It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or*
> something else, in some confusing ways.
> CommandLineHandler           #nextPutAll: (sent somewhere else)
> Integer                      left shift (someone has been smoking too 
> much C++)
> NonInteractiveTranscript     #show: = locked #print:
> SocketStream                 #putOn: (which may itself act like
>                               #nextPut:, #nextPutAll:, #print,
>                               put elements sans separators, or
>                               something else)
> Stream                       #putOn: (see above)
> WriteStream                  either #nextPutAll: or #putOn:
> Transcript                   #show: = locked #print:
> ThreadSafeTranscript         #show: = locked #print:
> VTermOutputDriver            #putOn:
> VTermOutputDriver2           #asString then #nextPutAll:
> ZnEncodedWriteStream         #nextPutAll:
> ZnHtmlOutputStream           #asString then #nextPutAll:
> SequenceableCollection class #streamContents:
> 
> As was once said about PL/I, #<< fills a much-needed gap.
> When I see #print:, or #nextPut:, or #nextPutAll:, I know
> what to expect.  When I see #putOn:, I have in general no
> idea what will happen.  And when I see << it is worse.

I don't think so. I have pretty coherent view of how << can work. In 
Amber this coherent view helped to create Silk library for DOM 
manipulation by treating a DOM element as a ind of a stream.

Having simple thing working (<< aCollection unpack the collection, 
having putOn: to be able to customize how object are put on stream) can 
help a lot; if, things are kept consistent.

> One point of << is to imitate C++'s composition of outputs.
> That might work, too, if only there were some agreement
> about what #nextPutAll: returns.  There is not.  It might
> return the receiver.  It might return some other stream
> related to the receiver.  It might even return the collection
> argument.  So when you see
>   a << b << c
> in general you not only do not have a clue what (a) is going
> to do with (b) but you have no idea what object the message
> << c will be sent to.


This is strawman. We know what str << a << b << c does if we know what 
is output of #<<, it has nothing to do with #nextPutAll:. And it's 
simple, STream >> << should return self, and we're done.

> Now let's see if we can puzzle out what
> Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ]
> does.
> The output will be going to a WriteStream.
> aWriteStream << anInteger
> is not, but is like, aWriteStream print: anInteger.
> So we add $1 and $0.
> aWriteStream << aString
> reduces to aWriteStream nextPutAll: aString.
> So we add $1 and $0.
> aWriteStream on anArray << anotherArray
> reduces to aWriteStream nextPutAll: anotherArray.
> So we add 10 and '10'.
> Thus the result we get is
> #($1 $0 $1 $0 10 '10').
> What result we should *expect* from this muddle I cannot say.

#(10 '10' 10 '10')

Of course.

After all, I put things on Array stream, which holds objects, not a 
character stream.

> If, on the other hand, you wrote explicitly
> Array streamContents: [:stream |
>    stream print: 10; nextPutAll: '10'; nextPutAll: #(10 '10')]
> you would have an easy time figuring out what to expect.

I see nextPut[All]: as low-level put API, and print:, write: and << as 
high-level one. I would not combine them.

I actually combine print: with write: to nice effect in Amber. Lot of 
code which actually export source to the disk uses combination of these 
two to enhance readability (IMO). For example:

exportTraitDefinitionOf: aClass on: aStream
	"Chunk format."

	aStream
		write: 'Trait named: '; printSymbol: aClass name; lf;
		tab; write: 'package: '; print:	aClass category; write: '!!'; lf.
	aClass comment ifNotEmpty: [
		aStream
		write: '!!'; print: aClass; write: ' commentStamp!!'; lf;
		write: { self chunkEscape: aClass comment. '!!' }; lf ].
	aStream lf

As write: and << are synonyms in Amber (so they probably was in some 
part of Pharo history), I chose to pair print: keyword selector with 
write: keyword selector from the style point of view.

Also, since write: is <<, I can write: a collection of pieces to put and 
I don't need to cascade lots of write:s.

What I wanted to illustrate is, good implementation of << can be pretty 
useful.

> By the way, there is no standard definition of #show:, but in
> other Smalltalk systems it's usually a variant of #nextPutAll:,
> not a variant of #print:.  There's no denying that locked output
> is useful to have, but #show: is not perhaps the best name for it.

Herby




More information about the Pharo-users mailing list