Hi Nicolas,

On Wed, 4 Mar 2020, Nicolas Cellier wrote:

> Hi all,
> on the other hand, there are remnants of very old "alternate syntax" experiments
> I have some "normalization" of syntax pending in order to reduce unjustified distance to cousin dialects.
> http://source.squeak.org/inbox/Compiler-nice.267.diff
> 
> Le mer. 4 mars 2020 à 14:04, Levente Uzonyi <leves at caesar.elte.hu> a écrit :
>       Hi All,
>
>       Answers inline. Rant alert!
>
>       On Wed, 4 Mar 2020, Thiede, Christoph wrote:
>
>       >
>       > Hi all,
>       >
>       >
>       > I took a look into the parser/scanner, let me ask you a few questions:
>       >
>       >
>       > Is it an important requirement that the compiler must be able to understand symbols such as #value::? Should these by valid symbols at all?
>
>       What are the consequences if you consider them not valid? What will break?
>       Why shouldn't they be valid? The most common "method names" are
>       #: #:: #::: #::::, etc (as in [ :x | ... ], [ :x :y | ... ], etc)
> 
> 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...
> Adding something is easy, removing is super hard (thus the changes aimed at removal tend to rot in inbox).

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".


Levente


>
>       >
>       > If not, we could change the following line in Scanner >> #xLetter:
>       >
>       >       tokenType := (type == #xColon and: [aheadChar ~~ $=] and: [aheadChar ~= $:])
>       >
>       > Otherwise, we could insert a validation of selector in #messagePart:repeat:. Something like:
>       >
>       >
>       >       selector readStream in: [:stream |
>
>       What's wrong with temporaries?
>       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.
> 
> +1
>
>       >   words do: [:word |
>       >   (stream take: word size - 1)
>
>       I had to look up what Stream >> #take: does. It's ^self any:
>       maxNumberOfElements. So, I had do look up what Stream >> #any: does.
>       Surprise, it's ^self next: numberOfElements.
>       Perhaps I'm getting too old, but I see no reason to use these methods
>       when you know the receiver is a stream.
>
>       Unfortunately neither methods have comments (#any: #take:), so one could
>       easily come to the conclusion that they are not very useful despite having
>       such generic names.
>
>       >   indexOf: $:
>       >   ifPresent: [:index | self notify: 'Argument expected' at: word start + index].
>
>       My image doesn't have #indexOf:ifPresent:.
> 
>
>       Levente
>
>       >   stream skip: 1]].
>       >
>       >
>       > Looking forward to your thoughts!
>       >
>       >
>       > Best,
>       >
>       > Christoph
>       >
>       >
>       >________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>       _
>       > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
>       > Gesendet: Freitag, 28. Februar 2020 14:17:20
>       > An: John Pfersich via Squeak-dev
>       > Betreff: Re: [squeak-dev] [BUG] Parser does not detect syntax error with double colon  
>       > Hi Christoph.
>       > Thanks for pointing this out. This issue has been around for like forever. :-) In Squeak 3.8, however, the list of choices was bigger:
>       >
>       > [IMAGE]
>       >
>       > Let's improve this in 6.0alpha :-)
>       >
>       > Best,
>       > Marcel
>       >
>       >       Am 28.02.2020 13:49:03 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
>       >
>       >       Steps to reproduce:
>       >
>       >       Try doIt this (for example, in a workspace):
>       >
>       >       2 raisedTo:: 3.
>       >
>       >
>       >       Expected behavior:
>       >
>       >       2 raisedTo:"Argument expected ->": 3.
>       >
>       >
>       >       Actual behavior:
>       >
>       >       [IMAGE]
>       >
>       >       If you are thumb enough to choose #raisedTo:: (I was), you get a subsequent error:
>       >
>       >       [IMAGE]
>       >
>       >       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:
>       >
>       >       MessageNotUnderstood: SmallInteger>>raisedTo::.
>       >
>       >
>       >       Best,
>       >
>       >       Christoph
>       >
>       >
>       >
> 
> 
>