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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 <[hidden email]>: > 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> If this is the consensus I can commit a slice that fixes the compiler
> and that rewrites the existing code. will we be able to identify them once rewritten? Yes [:a | nil] ? or [:a| ] > > 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 :) > > Lukas > > 2009/12/17 Stéphane Ducasse <[hidden email]>: >> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |