<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">

                                        Hi, there.<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Perhaps I'm getting too old, but I see no reason to use these methods</span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"> </span></div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">when you know the receiver is a stream.</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">That's right. :-) Both #any: and #take: are generic forms of #anyOne and #first: and similar for collections that are not necessarily sequenceable. The partial adaptation of the collection protocol for streams is still experimental. It is useful in scripting scenarios.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">"stream take: 42" does not make any sense.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">"streamOrCollection take: 42" can be quite useful. :-)</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>

                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">

                        <p style="color: #AAAAAA; margin-top: 10px;">Am 04.03.2020 14:04:27 schrieb Levente Uzonyi <leves@caesar.elte.hu>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi All,

<br>

Answers inline. Rant alert!

<br>

<br>On Wed, 4 Mar 2020, Thiede, Christoph wrote:

<br>

<br>> 

<br>> Hi all,

<br>> 

<br>> 

<br>> I took a look into the parser/scanner, let me ask you a few questions:

<br>> 

<br>> 

> Is it an important requirement that the compiler must be able to understand symbols such as #value::? Should these by valid symbols at all?

<br>

What are the consequences if you consider them not valid? What will break?

<br>Why shouldn't they be valid? The most common "method names" are 

<br>#: #:: #::: #::::, etc (as in [ :x | ... ], [ :x :y | ... ], etc)

<br>

<br>> 

<br>> If not, we could change the following line in Scanner >> #xLetter:

<br>>

<br>>       tokenType := (type == #xColon and: [aheadChar ~~ $=] and: [aheadChar ~= $:])

<br>> 

<br>> Otherwise, we could insert a validation of selector in #messagePart:repeat:. Something like:

<br>> 

<br>>

<br>>       selector readStream in: [:stream |

<br>

<br>What's wrong with temporaries? 

<br>I see #in: spreading like plague in methods. IMHO #in: is fine in scripts,

but I see no reason to use it as a replacement of temporaries in methods.

<br>

<br>>   words do: [:word |

<br>>   (stream take: word size - 1)

<br>

<br>I had to look up what Stream >> #take: does. It's ^self any: 

<br>maxNumberOfElements. So, I had do look up what Stream >> #any: does. 

Surprise, it's ^self next: numberOfElements.

<br>Perhaps I'm getting too old, but I see no reason to use these methods 

when you know the receiver is a stream.

<br>

<br>Unfortunately neither methods have comments (#any: #take:), so one could 

<br>easily come to the conclusion that they are not very useful despite having 

such generic names.

<br>

<br>>   indexOf: $:

>   ifPresent: [:index | self notify: 'Argument expected' at: word start + index].

<br>

My image doesn't have #indexOf:ifPresent:.

<br>

<br>

<br>Levente

<br>

<br>>   stream skip: 1]].

<br>> 

<br>> 

> Looking forward to your thoughts!

<br>> 

<br>> 

<br>> Best,

<br>> 

<br>> Christoph

<br>> 

<br>> 

<br>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________

<br>> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel

<br>> Gesendet: Freitag, 28. Februar 2020 14:17:20

<br>> An: John Pfersich via Squeak-dev

<br>> Betreff: Re: [squeak-dev] [BUG] Parser does not detect syntax error with double colon  

<br>> Hi Christoph.

<br>> Thanks for pointing this out. This issue has been around for like forever. :-) In Squeak 3.8, however, the list of choices was bigger:

<br>> 

<br>> [IMAGE]

<br>> 

<br>> Let's improve this in 6.0alpha :-)

<br>> 

<br>> Best,

<br>> Marcel

<br>>

<br>>       Am 28.02.2020 13:49:03 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:

<br>>

<br>>       Steps to reproduce:

<br>>

<br>>       Try doIt this (for example, in a workspace):

<br>>

<br>>       2 raisedTo:: 3.

<br>> 

<br>>

<br>>       Expected behavior:

<br>>

<br>>       2 raisedTo:"Argument expected ->": 3.

<br>> 

<br>>

<br>>       Actual behavior:

<br>>

<br>>       [IMAGE]

<br>>

<br>>       If you are thumb enough to choose #raisedTo:: (I was), you get a subsequent error:

<br>>

<br>>       [IMAGE]

<br>>

<br>>       Even worse: If you try to doIt the same code snippet again, no parser warning/error will be raised at all but you get a runtime error:

<br>>

<br>>       MessageNotUnderstood: SmallInteger>>raisedTo::.

<br>> 

<br>>

<br>>       Best,

<br>>

<br>>       Christoph

<br>> 

<br>> 

<br>><br></christoph.thiede@student.hpi.uni-potsdam.de></squeak-dev-bounces@lists.squeakfoundation.org></div></blockquote></div>