On 15.08.2019, at 03:29, Levente Uzonyi leves@caesar.elte.hu wrote:

On Wed, 14 Aug 2019, commits@source.squeak.org wrote:

...

A new version of ShoutCore was added to project The Inbox: http://source.squeak.org/inbox/ShoutCore-ct.69.mcz

==================== Summary ====================

Name: ShoutCore-ct.69 Author: ct Time: 14 August 2019, 10:43:04.7164 pm UUID: 7d165f4e-09bf-a445-a664-5e8edb9867b8 Ancestors: ShoutCore-ul.68

Fix bug in SHParserST80: Wrong styling after blocks with arguments without statements

If you mean that Shout should accept [ :x ], then no, I'm pretty sure that's not valid smalltalk syntax, even if Parser accepts it. The vertical bar, even though I consider it unnecessary in all cases, is mandatory when there are arguments.

I only got to know this "shortcut syntax" because eliot used it either Cog or somewhere in trunk when preparing something (Spur? full block closures? I forgot). So this is a syntax idiosyncrasy that is in active use, not only "old code".

Either we forbid it in the parser and change all of the image or allow it in Shout.

Best regards -Tobias

Levente

...

Thanks Jakob for the report!

=============== Diff against ShoutCore-ul.68 ===============

Item was changed: ----- Method: SHParserST80>>parseBlockArguments (in category 'parse') ----- parseBlockArguments

currentTokenFirst == $: ifFalse: [ ^self ]. [ currentTokenFirst == $: ] whileTrue: [ self scanPast: #blockArgColon; parseArgument: #blockPatternArg ].

• ((self parseVerticalBarForTemporaries: #blockArgsBar) and: [

• currentTokenFirst ~= $] ])
  

• 	ifFalse: [
  

• 		self fail ": Missing block args bar" ]!
  

• (self parseVerticalBarForTemporaries: #blockArgsBar) ifFalse: [

• self fail ": Missing block args bar" ]!
  

On Thu, 15 Aug 2019, Tobias Pape wrote:

...

On 15.08.2019, at 03:29, Levente Uzonyi leves@caesar.elte.hu wrote:

On Wed, 14 Aug 2019, commits@source.squeak.org wrote:

...

A new version of ShoutCore was added to project The Inbox: http://source.squeak.org/inbox/ShoutCore-ct.69.mcz

==================== Summary ====================

Name: ShoutCore-ct.69 Author: ct Time: 14 August 2019, 10:43:04.7164 pm UUID: 7d165f4e-09bf-a445-a664-5e8edb9867b8 Ancestors: ShoutCore-ul.68

Fix bug in SHParserST80: Wrong styling after blocks with arguments without statements

If you mean that Shout should accept [ :x ], then no, I'm pretty sure that's not valid smalltalk syntax, even if Parser accepts it. The vertical bar, even though I consider it unnecessary in all cases, is mandatory when there are arguments.

I only got to know this "shortcut syntax" because eliot used it either Cog or somewhere in trunk when preparing something (Spur? full block closures? I forgot). So this is a syntax idiosyncrasy that is in active use, not only "old code".

Either we forbid it in the parser and change all of the image or allow it in Shout.

Can you give me examples? I suspect those are just typos, which the parser accidentally accepted (and Shout as well before my fixes).

Levente

Best regards -Tobias

...

Levente

...

Thanks Jakob for the report!

=============== Diff against ShoutCore-ul.68 ===============

Item was changed: ----- Method: SHParserST80>>parseBlockArguments (in category 'parse') ----- parseBlockArguments

currentTokenFirst == $: ifFalse: [ ^self ]. [ currentTokenFirst == $: ] whileTrue: [ self scanPast: #blockArgColon; parseArgument: #blockPatternArg ].

• ((self parseVerticalBarForTemporaries: #blockArgsBar) and: [

• currentTokenFirst ~= $] ])
  

• 	ifFalse: [
  

• 		self fail ": Missing block args bar" ]!
  

• (self parseVerticalBarForTemporaries: #blockArgsBar) ifFalse: [

• self fail ": Missing block args bar" ]!
  

Hi Nicolas,

Thanks for investigating this. I still think that it's just a parser bug, which is accidentally "used" sometimes, especially because it only works when the block is empty. Or does it work in other dialects with non-empty blocks? Is it used in other dialects?

Levente

On Sun, 18 Aug 2019, Nicolas Cellier wrote:

Le jeu. 15 août 2019 à 12:21, Levente Uzonyi leves@caesar.elte.hu a écrit : On Thu, 15 Aug 2019, Tobias Pape wrote:

  >
  >> On 15.08.2019, at 03:29, Levente Uzonyi <leves@caesar.elte.hu> wrote:
  >>
  >> On Wed, 14 Aug 2019, commits@source.squeak.org wrote:
  >>
  >>> A new version of ShoutCore was added to project The Inbox:
  >>> http://source.squeak.org/inbox/ShoutCore-ct.69.mcz
  >>>
  >>> ==================== Summary ====================
  >>>
  >>> Name: ShoutCore-ct.69
  >>> Author: ct
  >>> Time: 14 August 2019, 10:43:04.7164 pm
  >>> UUID: 7d165f4e-09bf-a445-a664-5e8edb9867b8
  >>> Ancestors: ShoutCore-ul.68
  >>>
  >>> Fix bug in SHParserST80: Wrong styling after blocks with arguments without statements
  >>
  >> If you mean that Shout should accept [ :x ], then no, I'm pretty sure that's not valid smalltalk syntax, even if Parser accepts it.
  >> The vertical bar, even though I consider it unnecessary in all cases, is mandatory when there are arguments.
  >
  > I only got to know this "shortcut syntax" because eliot used it either Cog or somewhere in trunk when preparing something (Spur? full block closures? I forgot). So this is a syntax idiosyncrasy that is in active use, not only "old code".
  >
  > Either we forbid it in the parser and change all of the image or allow it in Shout.

  Can you give me examples?
  I suspect those are just typos, which the parser accidentally accepted
  (and Shout as well before my fixes).

  Levente

I don't remember seeing this syntax before and found it a bit surprising. So, for the sake of curiosity, I tried in some other dialects.

[:x ] is accepted syntax in

• Visualworks (8.3),
• Pharo (v7 with OpalCompiler)
• Smalltalk-80 (apple v0.?)

[:x ] is invalid in

• Dolphin
• Smalltalk/X (jv branch)

So it seems that it's something originating from original Smalltalk-80, but not reproducted in non derivated dialects...

The bar is mandatory in blue book specification (see the last pages)

Capture d’écran 2019-08-18 à 17.11.53.png So it seems that implementation did not agree with specifications for ages... Capture d’écran 2019-08-18 à 18.56.05.png

  >
  > Best regards
  >       -Tobias
  >
  >>
  >> Levente
  >>
  >>>
  >>> Thanks Jakob for the report!
  >>>
  >>> =============== Diff against ShoutCore-ul.68 ===============
  >>>
  >>> Item was changed:
  >>> ----- Method: SHParserST80>>parseBlockArguments (in category 'parse') -----
  >>> parseBlockArguments
  >>>
  >>>     currentTokenFirst == $: ifFalse: [ ^self ].
  >>>     [ currentTokenFirst == $: ] whileTrue: [
  >>>             self
  >>>                     scanPast: #blockArgColon;
  >>>                     parseArgument: #blockPatternArg ].
  >>> +   ((self parseVerticalBarForTemporaries: #blockArgsBar) and: [
  >>> +           currentTokenFirst ~= $] ])
  >>> +                   ifFalse: [
  >>> +                           self fail ": Missing block args bar" ]!
  >>> -   (self parseVerticalBarForTemporaries: #blockArgsBar) ifFalse: [
  >>> -           self fail ": Missing block args bar" ]!
  >>

The full definition from the draft standards (don’t have the standard handy) is:

<block constructor> ::= '[' <block body> ']' <block body> ::= [<block argument>* '|'] [<temporaries>] [<statements>] <block argument> ::= ':' identifier

The last line is on the next page of the draft.

/————————————————————/ For encrypted mail use jgpfersich@protonmail.com Get a free account at ProtonMail.com Web: www.objectnets.net and www.objectnets.org

On Aug 18, 2019, at 12:09, JOHN SARKELA via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:

The ANSI standard has the following rules for blocks: <block constructor> ::= '[' <block body> ']' <block body> ::= [<block argument>* '|'] [<temporaries>] [<statements>]

The standard does not recognize [:x] as legal syntax for a block.<page21image64736448.png> <page21image37471328.png> <page21image64735680.png> <page21image64733952.png> <page21image64746816.png>

...

On Aug 18, 2019, at 3:03 PM, Levente Uzonyi leves@caesar.elte.hu wrote:

Hi Nicolas,

Thanks for investigating this. I still think that it's just a parser bug, which is accidentally "used" sometimes, especially because it only works when the block is empty. Or does it work in other dialects with non-empty blocks? Is it used in other dialects?

Levente

...

On Sun, 18 Aug 2019, Nicolas Cellier wrote:

Le jeu. 15 août 2019 à 12:21, Levente Uzonyi leves@caesar.elte.hu a écrit : On Thu, 15 Aug 2019, Tobias Pape wrote:

 >
 >> On 15.08.2019, at 03:29, Levente Uzonyi <leves@caesar.elte.hu> wrote:
 >>
 >> On Wed, 14 Aug 2019, commits@source.squeak.org wrote:
 >>
 >>> A new version of ShoutCore was added to project The Inbox:
 >>> http://source.squeak.org/inbox/ShoutCore-ct.69.mcz
 >>>
 >>> ==================== Summary ====================
 >>>
 >>> Name: ShoutCore-ct.69
 >>> Author: ct
 >>> Time: 14 August 2019, 10:43:04.7164 pm
 >>> UUID: 7d165f4e-09bf-a445-a664-5e8edb9867b8
 >>> Ancestors: ShoutCore-ul.68
 >>>
 >>> Fix bug in SHParserST80: Wrong styling after blocks with arguments without statements
 >>
 >> If you mean that Shout should accept [ :x ], then no, I'm pretty sure that's not valid smalltalk syntax, even if Parser accepts it.
 >> The vertical bar, even though I consider it unnecessary in all cases, is mandatory when there are arguments.
 >
 > I only got to know this "shortcut syntax" because eliot used it either Cog or somewhere in trunk when preparing something (Spur? full block closures? I forgot). So this is a syntax idiosyncrasy that is in active use, not only "old code".
 >
 > Either we forbid it in the parser and change all of the image or allow it in Shout.

 Can you give me examples?
 I suspect those are just typos, which the parser accidentally accepted
 (and Shout as well before my fixes).

 Levente

I don't remember seeing this syntax before and found it a bit surprising. So, for the sake of curiosity, I tried in some other dialects. [:x ] is accepted syntax in

• Visualworks (8.3),
• Pharo (v7 with OpalCompiler)
• Smalltalk-80 (apple v0.?)

[:x ] is invalid in

• Dolphin
• Smalltalk/X (jv branch)

So it seems that it's something originating from original Smalltalk-80, but not reproducted in non derivated dialects... The bar is mandatory in blue book specification (see the last pages) Capture d’écran 2019-08-18 à 17.11.53.png So it seems that implementation did not agree with specifications for ages... Capture d’écran 2019-08-18 à 18.56.05.png

 >
 > Best regards
 >       -Tobias
 >
 >>
 >> Levente
 >>
 >>>
 >>> Thanks Jakob for the report!
 >>>
 >>> =============== Diff against ShoutCore-ul.68 ===============
 >>>
 >>> Item was changed:
 >>> ----- Method: SHParserST80>>parseBlockArguments (in category 'parse') -----
 >>> parseBlockArguments
 >>>
 >>>     currentTokenFirst == $: ifFalse: [ ^self ].
 >>>     [ currentTokenFirst == $: ] whileTrue: [
 >>>             self
 >>>                     scanPast: #blockArgColon;
 >>>                     parseArgument: #blockPatternArg ].
 >>> +   ((self parseVerticalBarForTemporaries: #blockArgsBar) and: [
 >>> +           currentTokenFirst ~= $] ])
 >>> +                   ifFalse: [
 >>> +                           self fail ": Missing block args bar" ]!
 >>> -   (self parseVerticalBarForTemporaries: #blockArgsBar) ifFalse: [
 >>> -           self fail ": Missing block args bar" ]!
 >>

On Mon, 19 Aug 2019, Nicolas Cellier wrote:

Le lun. 19 août 2019 à 03:37, John Pfersich via Squeak-dev squeak-dev@lists.squeakfoundation.org a écrit : The full definition from the draft standards (don’t have the standard handy) is: <block constructor> ::= '[' <block body> ']' <block body> ::= [<block argument>* '|'] [<temporaries>] [<statements>] <block argument> ::= ':' identifier

The last line is on the next page of the draft.

/————————————————————/For encrypted mail use jgpfersich@protonmail.comGet a free account at ProtonMail.com Web: www.objectnets.net and www.objectnets.org

On Aug 18, 2019, at 12:09, JOHN SARKELA via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:

  The ANSI standard has the following rules for blocks:

  <block constructor> ::= '[' <block body> ']'
  <block body> ::= [<block argument>* '|'] [<temporaries>] [<statements>]

The standard does not recognize [:x] as legal syntax for a block.<page21image64736448.png> <page21image37471328.png> <page21image64735680.png> <page21image64733952.png> <page21image64746816.png>

Yes, same as blue book. (block temporaries apart, this did not exist in st-80), bar is mandatory. On Aug 18, 2019, at 3:03 PM, Levente Uzonyi leves@caesar.elte.hu wrote:

Hi Nicolas,

Thanks for investigating this.

It's been a pretext for playing with historical material ;)

              I still think that it's just a parser bug, which is accidentally "used" sometimes, especially because it only works when the block is empty.

Seeing the code, it's the & (hereType ~~ #rightBracket) condition following (t1 size > 0 which makes [:x ] syntax possible. Since it has been added explicitely, my bet is that it has been added purposely and deliberataly rather than accidentally.

It seems [:x ] was not accepted in earlier version 00:

[block | blk argNodes argument | " '[' {:var.} (:var|statements) ']' BlockNode" argNodes ← (Vector new: 1) asStream. (self match: #leftBracket) ifTrue: [[(self match: #colon) and: [((argument ← self match: #word) ifTrue: [argNodes next← encoder autoBind: argument] ifFalse: [↑self expected: 'Argument name'])]] whileTrueDo: []. (argNodes empty or: [(self match: #verticalBar)]) false ifTrue: [↑self expected: 'Vertical bar']. ((blk ← self statements: argNodes contents doit: false) and: [(self match: #rightBracket)]) ifTrue: [↑blk]. ↑self expected: 'Period or right bracket'] ifFalse: [↑self expected: 'Left bracket']]. http://xeroxalto.computerhistory.org/Indigo/BasicDisks/Smalltalk14.bfs!1_/.s...

              Or does it work in other dialects with non-empty blocks?

Nope, the syntax is only for empty blocks. It could have worked for any block if we wanted to, because that vertical bar is just a decoration in blocks. From disambiguation POV, it's absolutely unecessary, the block arguments are already delimited by colon prefix :x Symetrically, we don't use such delimitation between method pattern and statements... But it evolved across history:

Historically, Smalltalk-76 did use a single (optional) bar for declaring temporaries (if any): methodDefnition := pattern [ '|' temporaries ] '[' statements ']'

Then early Smalltalk-80 method definitions did use empty temps systematically '[' pattern '|' '|' statements ']' The two bars were mandatory at that time

"374" LADParser$'Parser' [temporaries | vars | "[ '|' {variable} ] {variable, ..., variable}" (self match: #verticalBar) and: [((self match: #verticalBar) ifTrue: [↑#()]. vars ← (Vector new: 8) asStream. [hereType #word] whileTrueDo: [vars next← encoder bind: self advance]. (self match: #verticalBar) ifTrue: [↑vars contents])]. ↑self expected: 'Vertical bar']. http://xeroxalto.computerhistory.org/Indigo/BasicDisks/Smalltalk14.bfs!1_/.s...

I guess that current block syntax is the legacy from all these syntax evolutions/experiments...

Personnally, I like the bar, because it reminds me mathematical notation I learned at school for ensemble comprehension https://fr.wikipedia.org/wiki/Ensemble...

{x ∊ E | x even }

translated in Smalltalk:

E select: [:x | x even].

without bar, I'm really NOT used to it:     E select: [:x x even].

              Is it used in other dialects?

It is used in Squeak:

Context>>runSimulated: aBlock      "Simulate the execution of the argument, current. Answer the result it     returns."

^ thisContext sender      runSimulated: aBlock      contextAtEachStep: [:ignored]

"Context runSimulated: [Pen new defaultNib: 5; go: 100]"

See also MCMcdReader>>#loadPatch MCPatch>>#initializeWithBase:target:

There are 24 uses in my image, one from an external package: Xtreams:

CurrentReadOnlySourceFiles cacheDuring: [ | regex | regex := '[\s*:\s*\w+\s*]' asRegex. SystemNavigation default browseAllSelect: [ :method | regex search: method getSource asString ] ]

I also see two usages in VW, MethodContext>>#selector and BlockContext>>#selector. The fact that these two methods still have undescore (left arrow) assignment in source code and have same argument signature [:ignored] speaks for itself!!! I'm convinced that it's been an easy hack/feature originating in early 80s (probably by Dan Ingalls), and forgotten since, that never made it into the offical specifications. Smalltalk is malleable enough :)

We can deprecate it if we want, but we will have to support backward compatibility in the Parser. The boring side of frozen specs... In this case,we'd better not support it in Shout.

Most users just ignore the argument of an error handler block this way, but that's unnecessary in Squeak, because the block doesn't have to have any arguments:

[ self error ] on: Error do: [ "nothing" ]

But some users can't omit the block argument so easily, so perhaps its worth supporting this construct in Shout.

Levente

              Levente

              On Sun, 18 Aug 2019, Nicolas Cellier wrote:

                    Le jeu. 15 août 2019 à 12:21, Levente Uzonyi <leves@caesar.elte.hu> a écrit :
                         On Thu, 15 Aug 2019, Tobias Pape wrote:

                         >
                         >> On 15.08.2019, at 03:29, Levente Uzonyi <leves@caesar.elte.hu> wrote:
                         >>
                         >> On Wed, 14 Aug 2019, commits@source.squeak.org wrote:
                         >>
                         >>> A new version of ShoutCore was added to project The Inbox:
                         >>> http://source.squeak.org/inbox/ShoutCore-ct.69.mcz
                         >>>
                         >>> ==================== Summary ====================
                         >>>
                         >>> Name: ShoutCore-ct.69
                         >>> Author: ct
                         >>> Time: 14 August 2019, 10:43:04.7164 pm
                         >>> UUID: 7d165f4e-09bf-a445-a664-5e8edb9867b8
                         >>> Ancestors: ShoutCore-ul.68
                         >>>
                         >>> Fix bug in SHParserST80: Wrong styling after blocks with arguments without statements
                         >>
                         >> If you mean that Shout should accept [ :x ], then no, I'm pretty sure that's not valid smalltalk syntax, even if Parser accepts it.
                         >> The vertical bar, even though I consider it unnecessary in all cases, is mandatory when there are arguments.
                         >
                         > I only got to know this "shortcut syntax" because eliot used it either Cog or somewhere in trunk when preparing something (Spur? full block closures? I forgot). So this
                    is a syntax idiosyncrasy that is in active use, not only "old code".
                         >
                         > Either we forbid it in the parser and change all of the image or allow it in Shout.

                         Can you give me examples?
                         I suspect those are just typos, which the parser accidentally accepted
                         (and Shout as well before my fixes).

                         Levente
                    I don't remember seeing this syntax before and found it a bit surprising.
                    So, for the sake of curiosity, I tried in some other dialects.
                    [:x ] is accepted syntax in
                    - Visualworks (8.3),
                    - Pharo (v7 with OpalCompiler)
                    - Smalltalk-80 (apple v0.?)
                    [:x ] is invalid in
                    - Dolphin
                    - Smalltalk/X (jv branch)
                    So it seems that it's something originating from original Smalltalk-80, but not reproducted in non derivated dialects...
                    The bar is mandatory in blue book specification (see the last pages)
                    Capture d’écran 2019-08-18 à 17.11.53.png
                    So it seems that implementation did not agree with specifications for ages...
                    Capture d’écran 2019-08-18 à 18.56.05.png

                         >
                         > Best regards
                         >       -Tobias
                         >
                         >>
                         >> Levente
                         >>
                         >>>
                         >>> Thanks Jakob for the report!
                         >>>
                         >>> =============== Diff against ShoutCore-ul.68 ===============
                         >>>
                         >>> Item was changed:
                         >>> ----- Method: SHParserST80>>parseBlockArguments (in category 'parse') -----
                         >>> parseBlockArguments
                         >>>
                         >>>     currentTokenFirst == $: ifFalse: [ ^self ].
                         >>>     [ currentTokenFirst == $: ] whileTrue: [
                         >>>             self
                         >>>                     scanPast: #blockArgColon;
                         >>>                     parseArgument: #blockPatternArg ].
                         >>> +   ((self parseVerticalBarForTemporaries: #blockArgsBar) and: [
                         >>> +           currentTokenFirst ~= $] ])
                         >>> +                   ifFalse: [
                         >>> +                           self fail ": Missing block args bar" ]!
                         >>> -   (self parseVerticalBarForTemporaries: #blockArgsBar) ifFalse: [
                         >>> -           self fail ": Missing block args bar" ]!
                         >>

At the last SOB meeting we agreed that we would prefer the standard be enforced and that [:x] be considered improper. Make it sew, Mr Tailor...

On 2019-08-14, at 11:11 PM, Tobias Pape Das.Linux@gmx.de wrote:

...

On 15.08.2019, at 03:29, Levente Uzonyi leves@caesar.elte.hu wrote:

On Wed, 14 Aug 2019, commits@source.squeak.org wrote:

...

A new version of ShoutCore was added to project The Inbox: http://source.squeak.org/inbox/ShoutCore-ct.69.mcz

==================== Summary ====================

Name: ShoutCore-ct.69 Author: ct Time: 14 August 2019, 10:43:04.7164 pm UUID: 7d165f4e-09bf-a445-a664-5e8edb9867b8 Ancestors: ShoutCore-ul.68

Fix bug in SHParserST80: Wrong styling after blocks with arguments without statements

If you mean that Shout should accept [ :x ], then no, I'm pretty sure that's not valid smalltalk syntax, even if Parser accepts it. The vertical bar, even though I consider it unnecessary in all cases, is mandatory when there are arguments.

I only got to know this "shortcut syntax" because eliot used it either Cog or somewhere in trunk when preparing something (Spur? full block closures? I forgot). So this is a syntax idiosyncrasy that is in active use, not only "old code".

Either we forbid it in the parser and change all of the image or allow it in Shout.

Best regards -Tobias

...

Levente

...

Thanks Jakob for the report!

=============== Diff against ShoutCore-ul.68 ===============

Item was changed: ----- Method: SHParserST80>>parseBlockArguments (in category 'parse') ----- parseBlockArguments

currentTokenFirst == $: ifFalse: [ ^self ]. [ currentTokenFirst == $: ] whileTrue: [ self scanPast: #blockArgColon; parseArgument: #blockPatternArg ].

• ((self parseVerticalBarForTemporaries: #blockArgsBar) and: [

• currentTokenFirst ~= $] ])
  

• 	ifFalse: [
  

• 		self fail ": Missing block args bar" ]!
  

• (self parseVerticalBarForTemporaries: #blockArgsBar) ifFalse: [

• self fail ": Missing block args bar" ]!
  

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IO: Illogical Or

[Ugh, Nabble removed all my code examples again. Resend below:]

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Thiede, Christoph Gesendet: Montag, 10. Februar 2020 14:10 Uhr An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] [:x] considered improper (was Re: The Inbox: ShoutCore-ct.69.mcz)

Sorry for reviving this old thread ...

This is still an open issue, isn't it? (oh, it would be so comfortable if we had something like GitHub issues ...)

And just one related question: According to the BNF John mentioned --

<block constructor> ::= '[' <block body> ']' <block body> ::= [<block argument>* '|'] [<temporaries>] [<statements>] <block argument> ::= ':' identifier

(from the ANSI Smaltalk Standardhttps://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf#page=21,22) -- the following should be valid syntax as well, shouldn't it?

[|] value.

The explanation is that, according to Wikipedia, an asterisk in the BNF stands for "0 or more times". So provided that there is not a mistake in the official standard document, shouldn't we support the above example?

Which is the exact standard we are following? The Blue Book? The ANSI Smalltalk Standard?

Best, Christoph

-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Hi Levente,

alright, I like your arguments (sorry for the bad joke)! I would also not like to support [|] unless it's necessary.

How do you feel about Compiler-ct.417? Another, more expensive approach might be a SyntaxDeprecationWarning. :-)

Best,

Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Montag, 10. Februar 2020 22:46:42 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] [:x] considered improper (was Re: The Inbox: ShoutCore-ct.69.mcz)

Hi Christoph,

My understanding is that the conclusion was that [:x] should not be valid[1]. In my option, it makes no sense to support a useless extremal case. The BNF you posted below says that it is not valid.

But the BNF is from the ANSI standard's draft, so there's an extremely slim chance that it was changed in the actual standard. But - I doubt anyone would like to pay for it to find out - I'm not aware of any smalltalk implementation that would strictly follow the standard - the standard is not a good standard

In my option, [|] is another extremal case that I don't think we need to support. It's longer than [], and both parsers detect it the same way: the closing | of the temporary declaration is missing.

So, to sum it up, IMHO neither [:x], [:x :y] nor [|] should be supported. Parser accepts [:x] and [:x :y], which should be fixed; perhaps just a warning should be raised.

Levente

[1] http://forum.world.st/The-Inbox-ShoutCore-ct-69-mcz-tp5102398p5102912.html On Mon, 10 Feb 2020, Thiede, Christoph wrote:

[Ugh, Nabble removed all my code examples again. Resend below:]

---

Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Thiede, Christoph Gesendet: Montag, 10. Februar 2020 14:10 Uhr An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] [:x] considered improper (was Re: The Inbox: ShoutCore-ct.69.mcz) Sorry for reviving this old thread ...

This is still an open issue, isn't it? (oh, it would be so comfortable if we had something like GitHub issues ...)

And just one related question: According to the BNF John mentioned --

<block constructor> ::= '[' <block body> ']' <block body> ::= [<block argument>* '|'] [<temporaries>] [<statements>] <block argument> ::= ':' identifier (from the ANSI Smaltalk Standard) -- the following should be valid syntax as well, shouldn't it?

[|] value.

The explanation is that, according to Wikipedia, an asterisk in the BNF stands for "0 or more times". So provided that there is not a mistake in the official standard document, shouldn't we support the above example?

Which is the exact standard we are following? The Blue Book? The ANSI Smalltalk Standard?

Best, Christoph

-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Good point, but here is what it says about asterisks:

Within productions, alternatives are separated by a vertical bar ('|'), and typically listed on separate lines. Optional symbols are enclosed in square brackets ('[' and ']'). Symbols may also be grouped using parenthesis. The plus sign ('+') following a symbol or group of symbols indicates one or more repetitions; an asterisk ('*') indicates zero or more repetitions.

http://www.hpi.de/ So the standard is still "wrong" about [|] :-)

Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von John Pfersich via Squeak-dev squeak-dev@lists.squeakfoundation.org Gesendet: Donnerstag, 13. Februar 2020 12:09:54 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] [:x] considered improper (was Re: The Inbox: ShoutCore-ct.69.mcz)

Btw the standard uses a modified EBNF to describe the productions. That’s explained in the first part of the standard. Everything cascades in the standard, so you really need to commit to reading the whole standard, not the Wikipedia article. It’s a pain, but I’ve found it useful to do so. But then I’ve been a computer geek for 48 years, and this type of stuff is what I get paid to do. So nitpicking is my job.

/————————————————————/ For encrypted mail use jgpfersich@protonmail.com Get a free account at ProtonMail.com Web: https://objectnets.net and https://objectnets.org https://datascilv.com https://datascilv.org

On Feb 10, 2020, at 14:41, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:

The explanation is that, according to Wikipedia, an asterisk in the BNF stands for "0 or more times". So provided that there is not a mistake in the official standard document, shouldn't we support the above example?

Hi Christoph,

On Dec 6, 2021, at 9:02 AM, Christoph.Thiede@student.hpi.uni-potsdam.de wrote:

Hi all,

I'd like to push this discussion again before we ship the next release.

What do you think, can we finally disallow [:x] (without bar) via the Compiler? Or should we raise a DeprecationWarning at least? In the recent months, several occurences within the Trunk have already been adjusted.

From Wikipedia:

In microeconomic theory, opportunity cost, is what we get in return of an action[1] To elaborate, opportunity cost is the loss or the benefit that could have been enjoyed if the alternative choice was chosen. [2] As a representation of the relationship between scarcity and choice,[3] the objective of opportunity cost is to ensure efficient use of scarce resources.[4] It incorporates all associated costs of a decision, both explicit and implicit.[5] Opportunity cost also includes the utility or economic benefit an individual lost, it is indeed more than the monetary payment or actions taken. As an example, to go for a walk may not have any financial costs imbedded to it. Yet, the opportunity forgone is the time spent walking which could have been used instead for other purposes such as earning an income.[4]

IMO fixing this isn’t very important. And the effort in fixing it takes away effort that could be applied from doing something useful. There is a long list of things that we need to do, in the image, in the vm, in the community. If you want to work on something compiler related that would make a huge difference let me suggest quasi literals/template strings, with an attempt here: Inbox: Compiler.quasiliteral-eem.280 Tests.quasiliteral-eem.296

_,,,^..^,,,_ (phone)

Best, Christoph

---

Sent from Squeak Inbox Talk

Hi Eliot,

I'm open to hear different positions, but IMHO quasi literals/template strings/interpolation strings in Smalltalk would violate the central idea of a minimal set of syntax that fits on a postcard. My personal opinion is that with number suffices (1s), byte arrays, brace notation, etc., we have already blown up our syntax more than enough - that postcard will already cost you a lot of postage. And while I see the reasons behind these constructs, they still remaining syntax sugar or optimizations.

In particular about template strings, I think that they tend to impair readability as user strings and syntactical expressions are intermixed. Programmers are tempted to violate separation of concerns. Last but not least, we would need to adapt the tooling in the decompiler and Autocompletion and alternative parser implementations (Shout) and I don't know whatever else. In general, this change would make new Smalltalk code more likely to be incompatible with older environments.

Personally, I am a large friend of String >> #format: and think that it has always does us a good turn. *Maybe* we could talk about supporting keyword arguments in #format: - for instance:

'Hi {name}! You made {count} contributions this year to the package {package}!' format: (OrderedDictionary new at: #name put: 'eem'; at: #count put: 18; at: #package put: 'Kernel'; yourself)

If performance is crucial for you, you still could inline String >> #format: message sends. But I have the feeling that this will mainly only increase complexity in the Compiler/Decompiler logic.

(Apart from that, I'm having some loose ideas in mind on an implementation of #formatAttributes: - maybe in the holidays.)

Nevertheless, I am open to hear your thoughts behind this idea! :-)

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2021-12-06T09:49:58-08:00, eliot.miranda@gmail.com wrote:

And here are three relevant emails

https://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670...

https://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670...

https://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670...

_,,,^..^,,,_ (phone)

...

On Dec 6, 2021, at 9:41 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

Hi Christoph,

...

...

On Dec 6, 2021, at 9:02 AM, Christoph.Thiede at student.hpi.uni-potsdam.de wrote:

Hi all,

I'd like to push this discussion again before we ship the next release.

What do you think, can we finally disallow [:x] (without bar) via the Compiler? Or should we raise a DeprecationWarning at least? In the recent months, several occurences within the Trunk have already been adjusted.

From Wikipedia:

In microeconomic theory, opportunity cost, is what we get in return of an action[1] To elaborate, opportunity cost is the loss or the benefit that could have been enjoyed if the alternative choice was chosen. [2] As a representation of the relationship between scarcity and choice,[3] the objective of opportunity cost is to ensure efficient use of scarce resources.[4] It incorporates all associated costs of a decision, both explicit and implicit.[5] Opportunity cost also includes the utility or economic benefit an individual lost, it is indeed more than the monetary payment or actions taken. As an example, to go for a walk may not have any financial costs imbedded to it. Yet, the opportunity forgone is the time spent walking which could have been used instead for other purposes such as earning an income.[4]

IMO fixing this isn?t very important. And the effort in fixing it takes away effort that could be applied from doing something useful. There is a long list of things that we need to do, in the image, in the vm, in the community. If you want to work on something compiler related that would make a huge difference let me suggest quasi literals/template strings, with an attempt here: Inbox: Compiler.quasiliteral-eem.280 Tests.quasiliteral-eem.296

_,,,^..^,,,_ (phone)

...

Best, Christoph

---

Sent from Squeak Inbox Talk

I did pay for the standard and AFAICT there were no changes between the last draft and the issued standard. In my opinion, the standard is good as far as it went, which wasn’t too far. That’s why various Smalltalk implementations vary so much, as Christoph has found.

It can be a nontrivial task to port extensions from one dialect to another, even those derived from Squeak. Some dialects even claim they’re not even Smalltalk.

/————————————————————/ For encrypted mail use jgpfersich@protonmail.com Get a free account at ProtonMail.com Web: https://objectnets.net and https://objectnets.org https://datascilv.com https://datascilv.org

On Feb 10, 2020, at 13:46, Levente Uzonyi leves@caesar.elte.hu wrote:

Hi Christoph,

My understanding is that the conclusion was that [:x] should not be valid[1]. In my option, it makes no sense to support a useless extremal case. The BNF you posted below says that it is not valid.

But the BNF is from the ANSI standard's draft, so there's an extremely slim chance that it was changed in the actual standard. But

• I doubt anyone would like to pay for it to find out
• I'm not aware of any smalltalk implementation that would strictly follow the standard
• the standard is not a good standard

In my option, [|] is another extremal case that I don't think we need to support. It's longer than [], and both parsers detect it the same way: the closing | of the temporary declaration is missing.

So, to sum it up, IMHO neither [:x], [:x :y] nor [|] should be supported. Parser accepts [:x] and [:x :y], which should be fixed; perhaps just a warning should be raised.

Levente

[1] http://forum.world.st/The-Inbox-ShoutCore-ct-69-mcz-tp5102398p5102912.html

...

On Mon, 10 Feb 2020, Thiede, Christoph wrote:

[Ugh, Nabble removed all my code examples again. Resend below:] _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Thiede, Christoph Gesendet: Montag, 10. Februar 2020 14:10 Uhr An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] [:x] considered improper (was Re: The Inbox: ShoutCore-ct.69.mcz) Sorry for reviving this old thread ... This is still an open issue, isn't it? (oh, it would be so comfortable if we had something like GitHub issues ...) And just one related question: According to the BNF John mentioned -- <block constructor> ::= '[' <block body> ']' <block body> ::= [<block argument>* '|'] [<temporaries>] [<statements>] <block argument> ::= ':' identifier (from the ANSI Smaltalk Standard) -- the following should be valid syntax as well, shouldn't it? [|] value. The explanation is that, according to Wikipedia, an asterisk in the BNF stands for "0 or more times". So provided that there is not a mistake in the official standard document, shouldn't we support the above example? Which is the exact standard we are following? The Blue Book? The ANSI Smalltalk Standard? Best, Christoph -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html