If this is the consensus I can commit a slice that fixes the compiler and that rewrites the existing code. I will have to check all 60 empty blocks with arguments one by one. Most of them are used in exception handlers that do not use the return result, so this should mostly be a non-issue. Lukas 2009/12/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:

cool so I guess that we will aligned :)

On Dec 17, 2009, at 12:47 AM, Torsten Bergmann wrote:

...

Smalltalk/MT also returns nil

-- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Lukas Renggli http://www.lukas-renggli.ch

will we be able to identify them once rewritten? Yes [:a | nil] ? or [:a| ]

Well actually we could use this rewrite rule: RBParseTreeRewriter new replace: '[ :`arg :`@args | ]' withValueFrom: [ :block | block body addNode: block arguments last; parent ]; yourself It replaces all occurrences of empty blocks with one or more parameters with one that returns the the last argument. Like this we ensure the correct behavior for all existing code in the image even if we change the compiler to always return nil.

...

I will have to check all 60 empty blocks with arguments one by one. Most of them are used in exception handlers that do not use the return result, so this should mostly be a non-issue.

I would :) but let us see what the others think for now.

Lukas I'm still lookfing for the _  => := changes :)

Ok, I will provide a fix for Pharo 1.1 this morning. Then we have to figure out later how the Refactoring Engine, Shout and friends know how to parse. Lukas -- Lukas Renggli http://www.lukas-renggli.ch