Steps to reproduce:
Try doIt this (for example, in a workspace):
2 raisedTo:: 3.
Expected behavior:
2 raisedTo:"Argument expected ->": 3.
Actual behavior:
[cid:c80a10c0-c0f3-449a-b34d-733c44256241]
If you are thumb enough to choose #raisedTo:: (I was), you get a subsequent error:
[cid:c80d78da-81df-4634-82c0-1721a66c80c2]
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
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:
Let's improve this in 6.0alpha :-)
Best, Marcel
Am 28.02.2020 13:49:03 schrieb Thiede, Christoph christoph.thiede@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:
If you are thumb enough to choose #raisedTo:: (I was), you get a subsequent error:
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
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?
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 | words do: [:word | (stream take: word size - 1) indexOf: $: ifPresent: [:index | self notify: 'Argument expected' at: word start + index]. stream skip: 1]].
Looking forward to your thoughts!
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@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:
[cid:c5e6430d-9da0-4890-bf22-d5e98561f9b0]
Let's improve this in 6.0alpha :-)
Best, Marcel
Am 28.02.2020 13:49:03 schrieb Thiede, Christoph christoph.thiede@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:
[cid:c80a10c0-c0f3-449a-b34d-733c44256241]
If you are thumb enough to choose #raisedTo:: (I was), you get a subsequent error:
[cid:c80d78da-81df-4634-82c0-1721a66c80c2]
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
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 squeak-dev-bounces@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@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
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@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).
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@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@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
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@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@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@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 > > >
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 :)
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!
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@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@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@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@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@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@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
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@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@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@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@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@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@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@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 > > >
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@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@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@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@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@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@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@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@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@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 > > >
Hi Christoph,
On Sat, 7 Mar 2020, Thiede, Christoph wrote:
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?
No. By splitting up methods that way, you would create unnecessary small methods, which would result in hard-to-understand code. Just use temporaries, and follow common sense.
Beside of this interesting idiomatic discussion, I was actually interested whether you would rather install a fix in #xLetter or #messagePart:repeat: :-)
It depends. I would say #xLetter, but there a comment saying "Allow any number of embedded colons in literal symbols", and it's been there at least since 2002. Perhaps someone more familiar with Compiler's code can give you a better answer. :)
Levente
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@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@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@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@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@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@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@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@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 > > >
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@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
Hi Marcel,
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. :-)
Hmmm.... There really isn't much other shared API between the two, is there? Let's see:
Collection methodDictionary keys intersection: Stream methodDictionary keys "---> #(#printOn: #gather: #take: #reject: #contents #write: #any: #collect: #select:thenCollect: #do: #select:)"
Wow, that's actually more than I thought. Still, look at the size of the mismatch!
(Collection methodDictionary keys difference: Stream methodDictionary keys ) size "---> 162"
It kinda makes sense since, semantically, they're two *totally different* things. Even the ones that match, the semantics are not always the same. For example, #do: -- enumerates all elements in Collection, or *only the remaining* elements in Stream.
So I'm not so sure going further down the path of encouraging client code to interchange two such disparate objects was a good idea. Don't they usually take either/or as input convenience, but then use or convert to whatever it uses for internal implementation..
Best, Chris
Hmmm.... There really isn't much other shared API between the two, is there? Let's see:
Collection methodDictionary keys intersection: Stream methodDictionary
keys "---> #(#printOn: #gather: #take: #reject: #contents #write: #any: #collect: #select:thenCollect: #do: #select:)"
Not even #size can be there, since Stream's can't necessarily know it, but is the core attribute of any Collection...
squeak-dev@lists.squeakfoundation.org