<div dir="ltr"><div dir="ltr"><div>Hi all,</div><div>on the other hand, there are remnants of very old "alternate syntax" experiments</div><div>I have some "normalization" of syntax pending in order to reduce unjustified distance to cousin dialects.<br></div><div><a href="http://source.squeak.org/inbox/Compiler-nice.267.diff">http://source.squeak.org/inbox/Compiler-nice.267.diff</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 4 mars 2020 à 14:04, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div>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...</div><div>Adding something is easy, removing is super hard (thus the changes aimed at removal tend to rot in inbox).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <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></blockquote><div>+1</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>   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>
> Von: Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> 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 <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de" target="_blank">christoph.thiede@student.hpi.uni-potsdam.de</a>>:<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>
</blockquote></div></div>