Yes, when the compiler sees exp or: [ ... ] then it assumes that "exp" is a boolean-valued expression and generates code that fails if it isn't. Not all Smalltalk compilers perform this optimization, but it is very common. There are a bunch of methods treated like this, ifTrue:ifFalse: is another.
whileTrue: is an interesting slightly different case. The compiler usually optimizes whileTrue: only when both receiver and the argument are blocks. So, you can define whileTrue: in other classes without any problem.
-Ralph Johnson
On Sun, Sep 10, 2017 at 6:33 AM, Lorenz Köhl rainbowtwigs@gmail.com wrote:
[image: Boxbe] https://www.boxbe.com/overview This message is eligible for Automatic Cleanup! (rainbowtwigs@gmail.com) Add cleanup rule https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dd8UdKk6XBKefiw6WgR5jxiRs%252Bz4ZhdYH4NLF8y3Q1yo%253D%26token%3DCBHKUay%252FXiASnIShRk4i8Xwq5eeRqmxypuV1cDN%252BApJJ2u4Z4%252FQyrGmN6UBKpep9V2BaY%252FdQlkUFgiXKdY2jjkjIPnsaoNhAT20BWqPqLuX%252FZk%252BKFBJtacqPIMXss6tKcVEsQBe%252FncsPJAsw1rMWyw%253D%253D&tc_serial=32680703685&tc_rand=509028261&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001 | More info http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=32680703685&tc_rand=509028261&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001
I don't understand why Smalltalk doesn't allow me to have an or: method that takes a block argument (except on Boolean). For example:
Set or: 1. ==> MNU as expected.
Set or: [1]. ==> NonBooleanReceiver exception.
Set or: [:x | x] ==> Argument has too many arguments
Is it because the compiler specializes this to boolean when it sees the or: [ ... ] syntax? Is this a tradeoff made for performance?
greetings, Lorenz
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Ralph Johnson wrote
Yes, when the compiler sees exp or: [ ... ] then it assumes that "exp" is a boolean-valued expression and generates code that fails if it isn't.
I remember the pain of tripping over these little "everything is a message send to an object*" sins as a new Smalltalker. I wonder now, with the incredible speed of Cog, Spur, Sista, etc., if these devil's bargains from prior decades are still necessary. It would be psychologically satisfying (and nice for newbies) to remove the asterisk from the principle above.
----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Beginners-f107673.html
Sean P. DeNigris wrote on Sun, 17 Sep 2017 06:44:35 -0700 (MST)
Ralph Johnson wrote
Yes, when the compiler sees exp or: [ ... ] then it assumes that "exp" is a boolean-valued expression and generates code that fails if it isn't.
I remember the pain of tripping over these little "everything is a message send to an object*" sins as a new Smalltalker. I wonder now, with the incredible speed of Cog, Spur, Sista, etc., if these devil's bargains from prior decades are still necessary. It would be psychologically satisfying (and nice for newbies) to remove the asterisk from the principle above.
That was one of the changes between Self 1.0 and 2.0. The first version had a list of selectors it did special tricks for and it was annoying for programmers to have two code fragments that looked very similar to each other perform very differently. When Craig Chambers did the second generation compiler he noticed that he could handle all cases uniformly. The same should apply to Cog and Sista. Eliminating such tricks would hurt the interpreter, however.
-- Jecel
beginners@lists.squeakfoundation.org
-
Jecel Assumpcao Jr. -
Ralph Johnson -
Sean P. DeNigris