<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hi Levente,</p>
<p><br>
</p>
<p>could we agree on this: "redundant blocks" can be useful as the first step to identify the missing structure of a too-long method, but the next steps are to split up that method and transform the blocks into single methods?</p>
<p><br>
</p>
<p>Beside of this interesting idiomatic discussion, I was actually interested whether you would rather install a fix in #xLetter or #messagePart:repeat: :-)</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves@caesar.elte.hu><br>
<b>Gesendet:</b> Mittwoch, 4. März 2020 20:15:41<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] [BUG] Parser does not detect syntax error with double colon</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Christoph,<br>
<br>
On Wed, 4 Mar 2020, Thiede, Christoph wrote:<br>
<br>
> <br>
> Hi all,<br>
> <br>
> <br>
> thanks for your reactions!<br>
> <br>
> <br>
> > Well, those symbols actually don't exist at all. It's just a nice thing about the syntax that blocks look like as if they had those "empty selectors".<br>
> Wow, that's an interesting comparison :-)<br>
> <br>
> Re: code review: I wrote "something like this" to indicate pseudo smalltalk :)<br>
<br>
All right, I'll read it that way next time.<br>
<br>
> <br>
> Yes, you're right, this should be #next: instead of #take:.<br>
> <br>
> > What's wrong with temporaries?<br>
> <br>
> Their scope is possibly too large. Usually, this smell suggests you to introduce new methods (in this example: #checkKeywordsSelector:words:, for example). But in this context, it wouldn't match the overall abstraction level.<br>
> I'm rather a fan of the arbitrary method length in Metacello, by the way ... Plus, "readStream in:" introduces a nice analogy to #streamContents: IMHO. However, it was a pseudo script only ;-)<br>
> #messagePart:repeat: is a bit messy anyway. It changes the semantics of selector.<br>
> <br>
> > My image doesn't have #indexOf:ifPresent:.<br>
> <br>
> Neither does mine :-) I should propose them in another commit. #indexOf:[ifPresent:][ifAbsent:] ...<br>
> <br>
> So let me know which approach you recommend!<br>
<br>
Neither. I would only want to have those methods if the language didn't <br>
support temporaries.<br>
Of course, one could play with the idea to only use blocks and no method <br>
temporaries (as with #in:, #ifPresent:, #ifFound:, etc). It could even be <br>
a way to implement some sort of parallel "assignment". But that would be <br>
like using a different language, one with long lists of closing square <br>
brackets.<br>
<br>
<br>
Levente<br>
<br>
> <br>
> Best,<br>
> Christoph<br>
> <br>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves@caesar.elte.hu><br>
> Gesendet: Mittwoch, 4. März 2020 15:38 Uhr<br>
> An: The general-purpose Squeak developers list<br>
> Betreff: Re: [squeak-dev] [BUG] Parser does not detect syntax error with double colon  <br>
> Hi Nicolas,<br>
> <br>
> On Wed, 4 Mar 2020, Nicolas Cellier wrote:<br>
> <br>
> > Hi all,<br>
> > on the other hand, there are remnants of very old "alternate syntax" experiments<br>
> > I have some "normalization" of syntax pending in order to reduce unjustified distance to cousin dialects.<br>
> > <a href="http://source.squeak.org/inbox/Compiler-nice.267.diff">http://source.squeak.org/inbox/Compiler-nice.267.diff</a><br>
> ><br>
> > Le mer. 4 mars 2020 à 14:04, Levente Uzonyi <leves@caesar.elte.hu> a écrit :<br>
> >       Hi All,<br>
> ><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>
> >       ><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>
> ><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>
> > The question is as well why/when did we ever needed to introduce those selectors, because we do not lookup for blocks thru a selector...<br>
> > Adding something is easy, removing is super hard (thus the changes aimed at removal tend to rot in inbox).<br>
> <br>
> Well, those symbols actually don't exist at all. It's just a nice thing<br>
> about the syntax that blocks look like as if they had those<br>
> "empty selectors".<br>
> <br>
> <br>
> Levente<br>
> <br>
> <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,<br>
> >       but I see no reason to use it as a replacement of temporaries in methods.<br>
> ><br>
> > +1<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.<br>
> >       Surprise, it's ^self next: numberOfElements.<br>
> >       Perhaps I'm getting too old, but I see no reason to use these methods<br>
> >       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<br>
> >       such generic names.<br>
> ><br>
> >       >   indexOf: $:<br>
> >       >   ifPresent: [:index | self notify: 'Argument expected' at: word start + index].<br>
> ><br>
> >       My image doesn't have #indexOf:ifPresent:.<br>
> ><br>
> ><br>
> >       Levente<br>
> ><br>
> >       >   stream skip: 1]].<br>
> >       ><br>
> >       ><br>
> >       > Looking forward to your thoughts!<br>
> >       ><br>
> >       ><br>
> >       > Best,<br>
> >       ><br>
> >       > Christoph<br>
> >       ><br>
> >       ><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>
> ><br>
> ><br>
> ><br>
> <br>
> <br>
> <br>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
> Gesendet: Mittwoch, 4. März 2020 16:35 Uhr<br>
> An: Robert via Squeak-dev<br>
> Betreff: Re: [squeak-dev] [BUG] Parser does not detect syntax error with double colon  <br>
> Hi, there.<br>
> > Perhaps I'm getting too old, but I see no reason to use these methods <br>
> when you know the receiver is a stream.<br>
> 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<br>
> experimental. It is useful in scripting scenarios.<br>
> <br>
> "stream take: 42" does not make any sense.<br>
> "streamOrCollection take: 42" can be quite useful. :-)<br>
> <br>
> Best,<br>
> Marcel<br>
><br>
>       Am 04.03.2020 14:04:27 schrieb Levente Uzonyi <leves@caesar.elte.hu>:<br>
><br>
>       Hi All, <br>
><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>
>       > <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>
><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, <br>
>       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. <br>
>       Surprise, it's ^self next: numberOfElements. <br>
>       Perhaps I'm getting too old, but I see no reason to use these methods <br>
>       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 <br>
>       such generic names. <br>
><br>
>       >   indexOf: $: <br>
>       >   ifPresent: [:index | self notify: 'Argument expected' at: word start + index]. <br>
><br>
>       My image doesn't have #indexOf:ifPresent:. <br>
> <br>
><br>
>       Levente <br>
><br>
>       >   stream skip: 1]]. <br>
>       > <br>
>       > <br>
>       > Looking forward to your thoughts! <br>
>       > <br>
>       > <br>
>       > Best, <br>
>       > <br>
>       > Christoph <br>
>       > <br>
>       > <br>
>       >________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
>       _ <br>
>       > Von: Squeak-dev 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 : <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>
> <br>
> <br>
> <br>
></div>
</span></font>
</body>
</html>