[squeak-dev] [BUG] Parser does not detect syntax error with double colon

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Mar 7 13:45:27 UTC 2020


Hi Levente,


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?


Beside of this interesting idiomatic discussion, I was actually interested whether you would rather install a fix in #xLetter or #messagePart:repeat: :-)


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves at caesar.elte.hu>
Gesendet: Mittwoch, 4. März 2020 20:15:41
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [BUG] Parser does not detect syntax error with double colon

Hi Christoph,

On Wed, 4 Mar 2020, Thiede, Christoph wrote:

>
> Hi all,
>
>
> thanks for your reactions!
>
>
> > 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".
> Wow, that's an interesting comparison :-)
>
> Re: code review: I wrote "something like this" to indicate pseudo smalltalk :)

All right, I'll read it that way next time.

>
> Yes, you're right, this should be #next: instead of #take:.
>
> > What's wrong with temporaries?
>
> 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.
> 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 ;-)
> #messagePart:repeat: is a bit messy anyway. It changes the semantics of selector.
>
> > My image doesn't have #indexOf:ifPresent:.
>
> Neither does mine :-) I should propose them in another commit. #indexOf:[ifPresent:][ifAbsent:] ...
>
> So let me know which approach you recommend!

Neither. I would only want to have those methods if the language didn't
support temporaries.
Of course, one could play with the idea to only use blocks and no method
temporaries (as with #in:, #ifPresent:, #ifFound:, etc). It could even be
a way to implement some sort of parallel "assignment". But that would be
like using a different language, one with long lists of closing square
brackets.


Levente

>
> Best,
> Christoph
>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves at caesar.elte.hu>
> Gesendet: Mittwoch, 4. März 2020 15:38 Uhr
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] [BUG] Parser does not detect syntax error with double colon
> 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
> >       >
> >       >
> >       >
> >
> >
> >
>
>
>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
> Gesendet: Mittwoch, 4. März 2020 16:35 Uhr
> An: Robert via Squeak-dev
> Betreff: Re: [squeak-dev] [BUG] Parser does not detect syntax error with double colon
> Hi, there.
> > Perhaps I'm getting too old, but I see no reason to use these methods
> when you know the receiver is a stream.
> 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.
>
> "stream take: 42" does not make any sense.
> "streamOrCollection take: 42" can be quite useful. :-)
>
> Best,
> Marcel
>
>       Am 04.03.2020 14:04:27 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
>
>       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)
>
>       >
>       > 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.
>
>       >   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 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 :
>       >
>       > 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
>       >
>       >
>       >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200307/635825b7/attachment.html>


More information about the Squeak-dev mailing list