April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Moose-dev] Re: collection>>sum:

by Nicolas Cellier

Or maybe sumEach: #squared... Anyway, current Squeak #detectSum: sounds awful, so it shouldn't be hard to find a better name 2013/4/22 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Personnally, I like #sumOf:, like for example (1 to: 10) sumOf: #squared. > Same with maxOf: minOf: productOf: ... > > > 2013/4/22 Frank Shearar <frank.shearar(a)gmail.com> > >> On 22 April 2013 12:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > Hi, >> > >> > I agree with Frank on the processing block: it has nothing to do with >> summing. >> > >> > Mathematically, defining adding (sum) leads to a neutral element >> (zero). But you only need it if the collection is empty. >> > >> > The trick of the #zero selector is elegant, but not needed with the >> #anyOne trick. >> >> That's a good point. I thought of #zero because my own hacking on >> SqueakCheck led naturally to thinking of protocols: using a class-side >> #zero means that I could work with "all objects that understand + and >> have a zero". >> >> #collectAndSum: might be a good name for the method, actually. >> >> frank >> >> > Currently, #sum does not work with empty collections in Pharo, which >> surprised me. >> > >> > I would add a >> > >> > Collection>>#sumFrom: value >> > ^ self inject: value into: [ :sum :each | sum + each ] >> > >> > And change >> > >> > Collection>>#sum >> > | sample sum | >> > self isEmpty ifTrue: [ ^ self sumFrom: 0 ]. >> > sample := self anyOne. >> > sum := self inject: sample into: [ :sum :each | sum + each ]. >> > ^ sum - sample >> > >> > A variant with an additional collect style processing block could be >> added along these lines, #sum: and #sum:from: >> > >> > Sven >> > >> > On 22 Apr 2013, at 12:29, Frank Shearar <frank.shearar(a)gmail.com> >> wrote: >> > >> >> "Sum" is usually well-defined, so I don't understand what the block's >> >> for. With the block it's more like "take this collection, map the >> >> values with some function, and sum the result". >> >> >> >> If so, it sounds like you're looking for a sugared form of >> >> (myCollection collect: aBlock) inject: self first class zero into: #+. >> >> ? >> >> >> >> (There's already Float class >> #zero and (in Squeak at least) Integer >> >> class >> #zero, and so on. Just add MyUnit class >> #zero and you're >> >> done.) >> >> >> >> frank >> >> >> >> On 22 April 2013 10:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >> >>> >> >>> I am CC-ing the pharo mailing list because it can be of interest. >> >>> >> >>> I agree with Guillaume that there is a legitimate need for a generic >> >>> solution. However, at the same time we lose the convenience of simply >> adding >> >>> numbers, which is likely to be the most encountered use case. >> >>> >> >>> I see a couple of possibilities: >> >>> - add Collection>>sum: aBlock from: aZeroValue that takes aZeroValue >> as the >> >>> default. >> >>> - add Collection>>sumNumbers: aBlock that takes 0 as default rather >> than >> >>> anyOne. >> >>> >> >>> What do you think? >> >>> >> >>> Cheers, >> >>> Doru >> >>> >> >>> >> >>> >> >>> On Mon, Apr 22, 2013 at 10:14 AM, Guillaume Larcheveque >> >>> <guillaume.larcheveque(a)gmail.com> wrote: >> >>>> >> >>>> For example, in Artefact we use Units and I have tried to use sum >> but it >> >>>> doesn't works because Units doesn't allow to do 0 + 4 cm which is >> >>>> inconsistent. >> >>>> >> >>>> >> >>>> 2013/4/22 Alexandre Bergel <alexandre.bergel(a)me.com> >> >>>>> >> >>>>> Thanks for letting us know. I cannot see a case where having 0 as >> the >> >>>>> initial value does not work as expected. >> >>>>> >> >>>>> Cheers, >> >>>>> Alexandre >> >>>>> >> >>>>> >> >>>>> Le 21 avr. 2013 Ã 17:35, Tudor Girba <tudor(a)tudorgirba.com> a >> Ã©crit : >> >>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> Pharo 2.0 comes with Collection>>sum: >> >>>>>> >> >>>>>> Collection>>sum: aBlock >> >>>>>> "This is implemented using a variant of the normal inject:into: >> >>>>>> pattern. >> >>>>>> The reason for this is that it is not known whether we're in the >> >>>>>> normal >> >>>>>> number line, i.e. whether 0 is a good initial value for the sum. >> >>>>>> Consider a collection of measurement objects, 0 would be the >> >>>>>> unitless >> >>>>>> value and would not be appropriate to add with the unit-ed >> objects." >> >>>>>> | sum sample | >> >>>>>> sample := aBlock value: self anyOne. >> >>>>>> sum := self inject: sample into: [ :previousValue :each | >> >>>>>> previousValue + (aBlock value: each) ]. >> >>>>>> ^ sum - sample >> >>>>>> >> >>>>>> To some extent, this is more generic than the one we had in Moose >> that >> >>>>>> considered only numbers: >> >>>>>> Collection>>sum: aSymbolOrBlock >> >>>>>> ^ self >> >>>>>> inject: 0 >> >>>>>> into: [:sum :each | sum + (aSymbolOrBlock value: each)] >> >>>>>> >> >>>>>> >> >>>>>> However, with the Pharo 2.0 implementation the collection must not >> be >> >>>>>> empty, while the other implementation we get 0. If the collection >> is empty, >> >>>>>> you get an exception due to anyOne. >> >>>>>> >> >>>>>> This induced several errors in metric computations (like number of >> >>>>>> methods of a package when the package had no classes). These are >> now fixed, >> >>>>>> but I thought I would let you know just in case you want to rely >> on this >> >>>>>> method. >> >>>>>> >> >>>>>> I actually still believe we would benefit from a robust but more >> >>>>>> limited sum:. Perhaps we could have sumNumbers:. >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Doru >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> www.tudorgirba.com >> >>>>>> >> >>>>>> "If you can't say why something is relevant, >> >>>>>> it probably isn't." >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Moose-dev mailing list >> >>>>>> Moose-dev(a)iam.unibe.ch >> >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Moose-dev mailing list >> >>>>> Moose-dev(a)iam.unibe.ch >> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>>> >> >>>> >> >>>> -- >> >>>> Guillaume Larcheveque >> >>>> >> >>>> _______________________________________________ >> >>>> Moose-dev mailing list >> >>>> Moose-dev(a)iam.unibe.ch >> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> >> >>> -- >> >>> www.tudorgirba.com >> >>> >> >>> "Every thing has its own flow" >> > >> > >> > -- >> > Sven Van Caekenberghe >> > Proudly supporting Pharo >> > http://pharo.org >> > http://association.pharo.org >> > http://consortium.pharo.org >> > >> > >> > >> > >> > >> >> >

April 22, 2013

Re: [Pharo-project] [Moose-dev] Re: collection>>sum:

by Nicolas Cellier

Personnally, I like #sumOf:, like for example (1 to: 10) sumOf: #squared. Same with maxOf: minOf: productOf: ... 2013/4/22 Frank Shearar <frank.shearar(a)gmail.com> > On 22 April 2013 12:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > > > I agree with Frank on the processing block: it has nothing to do with > summing. > > > > Mathematically, defining adding (sum) leads to a neutral element (zero). > But you only need it if the collection is empty. > > > > The trick of the #zero selector is elegant, but not needed with the > #anyOne trick. > > That's a good point. I thought of #zero because my own hacking on > SqueakCheck led naturally to thinking of protocols: using a class-side > #zero means that I could work with "all objects that understand + and > have a zero". > > #collectAndSum: might be a good name for the method, actually. > > frank > > > Currently, #sum does not work with empty collections in Pharo, which > surprised me. > > > > I would add a > > > > Collection>>#sumFrom: value > > ^ self inject: value into: [ :sum :each | sum + each ] > > > > And change > > > > Collection>>#sum > > | sample sum | > > self isEmpty ifTrue: [ ^ self sumFrom: 0 ]. > > sample := self anyOne. > > sum := self inject: sample into: [ :sum :each | sum + each ]. > > ^ sum - sample > > > > A variant with an additional collect style processing block could be > added along these lines, #sum: and #sum:from: > > > > Sven > > > > On 22 Apr 2013, at 12:29, Frank Shearar <frank.shearar(a)gmail.com> wrote: > > > >> "Sum" is usually well-defined, so I don't understand what the block's > >> for. With the block it's more like "take this collection, map the > >> values with some function, and sum the result". > >> > >> If so, it sounds like you're looking for a sugared form of > >> (myCollection collect: aBlock) inject: self first class zero into: #+. > >> ? > >> > >> (There's already Float class >> #zero and (in Squeak at least) Integer > >> class >> #zero, and so on. Just add MyUnit class >> #zero and you're > >> done.) > >> > >> frank > >> > >> On 22 April 2013 10:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>> Hi, > >>> > >>> I am CC-ing the pharo mailing list because it can be of interest. > >>> > >>> I agree with Guillaume that there is a legitimate need for a generic > >>> solution. However, at the same time we lose the convenience of simply > adding > >>> numbers, which is likely to be the most encountered use case. > >>> > >>> I see a couple of possibilities: > >>> - add Collection>>sum: aBlock from: aZeroValue that takes aZeroValue > as the > >>> default. > >>> - add Collection>>sumNumbers: aBlock that takes 0 as default rather > than > >>> anyOne. > >>> > >>> What do you think? > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> > >>> On Mon, Apr 22, 2013 at 10:14 AM, Guillaume Larcheveque > >>> <guillaume.larcheveque(a)gmail.com> wrote: > >>>> > >>>> For example, in Artefact we use Units and I have tried to use sum but > it > >>>> doesn't works because Units doesn't allow to do 0 + 4 cm which is > >>>> inconsistent. > >>>> > >>>> > >>>> 2013/4/22 Alexandre Bergel <alexandre.bergel(a)me.com> > >>>>> > >>>>> Thanks for letting us know. I cannot see a case where having 0 as the > >>>>> initial value does not work as expected. > >>>>> > >>>>> Cheers, > >>>>> Alexandre > >>>>> > >>>>> > >>>>> Le 21 avr. 2013 Ã 17:35, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit > : > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Pharo 2.0 comes with Collection>>sum: > >>>>>> > >>>>>> Collection>>sum: aBlock > >>>>>> "This is implemented using a variant of the normal inject:into: > >>>>>> pattern. > >>>>>> The reason for this is that it is not known whether we're in the > >>>>>> normal > >>>>>> number line, i.e. whether 0 is a good initial value for the sum. > >>>>>> Consider a collection of measurement objects, 0 would be the > >>>>>> unitless > >>>>>> value and would not be appropriate to add with the unit-ed > objects." > >>>>>> | sum sample | > >>>>>> sample := aBlock value: self anyOne. > >>>>>> sum := self inject: sample into: [ :previousValue :each | > >>>>>> previousValue + (aBlock value: each) ]. > >>>>>> ^ sum - sample > >>>>>> > >>>>>> To some extent, this is more generic than the one we had in Moose > that > >>>>>> considered only numbers: > >>>>>> Collection>>sum: aSymbolOrBlock > >>>>>> ^ self > >>>>>> inject: 0 > >>>>>> into: [:sum :each | sum + (aSymbolOrBlock value: each)] > >>>>>> > >>>>>> > >>>>>> However, with the Pharo 2.0 implementation the collection must not > be > >>>>>> empty, while the other implementation we get 0. If the collection > is empty, > >>>>>> you get an exception due to anyOne. > >>>>>> > >>>>>> This induced several errors in metric computations (like number of > >>>>>> methods of a package when the package had no classes). These are > now fixed, > >>>>>> but I thought I would let you know just in case you want to rely on > this > >>>>>> method. > >>>>>> > >>>>>> I actually still believe we would benefit from a robust but more > >>>>>> limited sum:. Perhaps we could have sumNumbers:. > >>>>>> > >>>>>> Cheers, > >>>>>> Doru > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> www.tudorgirba.com > >>>>>> > >>>>>> "If you can't say why something is relevant, > >>>>>> it probably isn't." > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Moose-dev mailing list > >>>>>> Moose-dev(a)iam.unibe.ch > >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>> > >>>>> _______________________________________________ > >>>>> Moose-dev mailing list > >>>>> Moose-dev(a)iam.unibe.ch > >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>> > >>>> > >>>> -- > >>>> Guillaume Larcheveque > >>>> > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> Moose-dev(a)iam.unibe.ch > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > > > > > > -- > > Sven Van Caekenberghe > > Proudly supporting Pharo > > http://pharo.org > > http://association.pharo.org > > http://consortium.pharo.org > > > > > > > > > > > >

April 22, 2013

Re: [Pharo-project] (was: Moose-dev) #stable and Metacello

by Diego Lont

Dale, Stef, I like to have "a recommended version" as default and not #'stable'. Because I still want to recommend a version, even is this isn't stable. I can use the blessings to mark it as "development" or "release". Using a 'recommended version' also makes it clear, that it depends on the project (both using as used) wether is is wise to use this version or not. For Moose 4.8 the 'recommended version' is the release candidate. Diego On Apr 18, 2013, at 9:55 PM, stephane ducasse wrote: > > On Apr 18, 2013, at 6:29 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> Stef, >> >> I think it is clear that #stable is not the right name, but I also think it is better to have one "badly named," commonly used symbolic version rather than a bunch of different names for the same thingâ¦ > > yes > but this can be confusing. >> Eventually we should change the convention, but I don't think we need to hurry and do so:) > > first we need a tool to manage configuration for real. > > Stef > >> >> Dale >> >> ----- Original Message ----- >> | From: "stephane ducasse" <stephane.ducasse(a)free.fr> >> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> >> | Sent: Wednesday, April 17, 2013 10:04:50 PM >> | Subject: [Moose-dev] Re: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside) >> | >> | Dale >> | >> | I thought that stable should be called milestoneDevelopment. >> | I will add a note to the metacello chapter and versionner will handle the >> | patterns we see. >> | >> | Stef >> |

April 22, 2013

Re: [Pharo-project] [Moose-dev] Re: collection>>sum:

by Frank Shearar

On 22 April 2013 12:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I agree with Frank on the processing block: it has nothing to do with summing. > > Mathematically, defining adding (sum) leads to a neutral element (zero). But you only need it if the collection is empty. > > The trick of the #zero selector is elegant, but not needed with the #anyOne trick. That's a good point. I thought of #zero because my own hacking on SqueakCheck led naturally to thinking of protocols: using a class-side #zero means that I could work with "all objects that understand + and have a zero". #collectAndSum: might be a good name for the method, actually. frank > Currently, #sum does not work with empty collections in Pharo, which surprised me. > > I would add a > > Collection>>#sumFrom: value > ^ self inject: value into: [ :sum :each | sum + each ] > > And change > > Collection>>#sum > | sample sum | > self isEmpty ifTrue: [ ^ self sumFrom: 0 ]. > sample := self anyOne. > sum := self inject: sample into: [ :sum :each | sum + each ]. > ^ sum - sample > > A variant with an additional collect style processing block could be added along these lines, #sum: and #sum:from: > > Sven > > On 22 Apr 2013, at 12:29, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> "Sum" is usually well-defined, so I don't understand what the block's >> for. With the block it's more like "take this collection, map the >> values with some function, and sum the result". >> >> If so, it sounds like you're looking for a sugared form of >> (myCollection collect: aBlock) inject: self first class zero into: #+. >> ? >> >> (There's already Float class >> #zero and (in Squeak at least) Integer >> class >> #zero, and so on. Just add MyUnit class >> #zero and you're >> done.) >> >> frank >> >> On 22 April 2013 10:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hi, >>> >>> I am CC-ing the pharo mailing list because it can be of interest. >>> >>> I agree with Guillaume that there is a legitimate need for a generic >>> solution. However, at the same time we lose the convenience of simply adding >>> numbers, which is likely to be the most encountered use case. >>> >>> I see a couple of possibilities: >>> - add Collection>>sum: aBlock from: aZeroValue that takes aZeroValue as the >>> default. >>> - add Collection>>sumNumbers: aBlock that takes 0 as default rather than >>> anyOne. >>> >>> What do you think? >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Mon, Apr 22, 2013 at 10:14 AM, Guillaume Larcheveque >>> <guillaume.larcheveque(a)gmail.com> wrote: >>>> >>>> For example, in Artefact we use Units and I have tried to use sum but it >>>> doesn't works because Units doesn't allow to do 0 + 4 cm which is >>>> inconsistent. >>>> >>>> >>>> 2013/4/22 Alexandre Bergel <alexandre.bergel(a)me.com> >>>>> >>>>> Thanks for letting us know. I cannot see a case where having 0 as the >>>>> initial value does not work as expected. >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>> Le 21 avr. 2013 Ã 17:35, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >>>>> >>>>>> Hi, >>>>>> >>>>>> Pharo 2.0 comes with Collection>>sum: >>>>>> >>>>>> Collection>>sum: aBlock >>>>>> "This is implemented using a variant of the normal inject:into: >>>>>> pattern. >>>>>> The reason for this is that it is not known whether we're in the >>>>>> normal >>>>>> number line, i.e. whether 0 is a good initial value for the sum. >>>>>> Consider a collection of measurement objects, 0 would be the >>>>>> unitless >>>>>> value and would not be appropriate to add with the unit-ed objects." >>>>>> | sum sample | >>>>>> sample := aBlock value: self anyOne. >>>>>> sum := self inject: sample into: [ :previousValue :each | >>>>>> previousValue + (aBlock value: each) ]. >>>>>> ^ sum - sample >>>>>> >>>>>> To some extent, this is more generic than the one we had in Moose that >>>>>> considered only numbers: >>>>>> Collection>>sum: aSymbolOrBlock >>>>>> ^ self >>>>>> inject: 0 >>>>>> into: [:sum :each | sum + (aSymbolOrBlock value: each)] >>>>>> >>>>>> >>>>>> However, with the Pharo 2.0 implementation the collection must not be >>>>>> empty, while the other implementation we get 0. If the collection is empty, >>>>>> you get an exception due to anyOne. >>>>>> >>>>>> This induced several errors in metric computations (like number of >>>>>> methods of a package when the package had no classes). These are now fixed, >>>>>> but I thought I would let you know just in case you want to rely on this >>>>>> method. >>>>>> >>>>>> I actually still believe we would benefit from a robust but more >>>>>> limited sum:. Perhaps we could have sumNumbers:. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "If you can't say why something is relevant, >>>>>> it probably isn't." >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> -- >>>> Guillaume Larcheveque >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

April 22, 2013

[Pharo-project] [update 3.0] #30053

by Marcus Denker

April 22, 2013

Re: [Pharo-project] Question about AST annotation scopes order

by Marcus Denker

On Apr 22, 2013, at 1:33 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > In Opal, self, super, thiscontex is in the Method Scope while self and super is in the > Instance scope. > > So the lookup is > > temps + thisContext > ivars + self + super > literal vars > > I want it :) it is in the imageâ¦ it's a complete parallel implementation. | ast | ast := (RBParser parseMethod: 'do ^thisContext'). ast doSemanticAnalysis. ast body statements first value ocBinding isTemp --> false

April 22, 2013

Re: [Pharo-project] Question about AST annotation scopes order

by Guillermo Polito

On Mon, Apr 22, 2013 at 1:30 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Apr 22, 2013, at 1:23 PM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > Hi! > > > > I'm taking a look at the AST annotation in > > > > RBProgramNode>>annotateInClass: aBehavior > > self annotateInScope: (RBVariableScope > > owner: (RBLiteralScope > > owner: RBRootScope new > > class: aBehavior) > > class: aBehavior) > > > > With that code, the order in which variables are annotated is > > > > 1) inst vars > > 2) literal vars (class vars, pools, globals in the environment) > > 3) the root scope -> pseudo-vars (self, super, thiscontext) > > > > Shouldn't the order be different? Something like: > > > > 1) pseudo-vars (self, super, thiscontext) > > 2) inst vars > > 3) literal vars (class vars, pools, globals in the environment) > > > > So there are never conflicts, and no other scope can bind pseudo-vars? > > Hello, > > For now Opal is not using the semantic analysis of AST-Semantics but > instead it's own. > (it is more low-level with escaping variables and things like that). > > So the goal is to merge the two. > > What I wanted to say: No idea. :-) > > In Opal, self, super, thiscontex is in the Method Scope while self and > super is in the > Instance scope. > > So the lookup is > > temps + thisContext > ivars + self + super > literal vars > I want it :) > > Marcus > > >

April 22, 2013

Re: [Pharo-project] [Moose-dev] Re: collection>>sum:

by Sven Van Caekenberghe

Hi, I agree with Frank on the processing block: it has nothing to do with summing. Mathematically, defining adding (sum) leads to a neutral element (zero). But you only need it if the collection is empty. The trick of the #zero selector is elegant, but not needed with the #anyOne trick. Currently, #sum does not work with empty collections in Pharo, which surprised me. I would add a Collection>>#sumFrom: value ^ self inject: value into: [ :sum :each | sum + each ] And change Collection>>#sum | sample sum | self isEmpty ifTrue: [ ^ self sumFrom: 0 ]. sample := self anyOne. sum := self inject: sample into: [ :sum :each | sum + each ]. ^ sum - sample A variant with an additional collect style processing block could be added along these lines, #sum: and #sum:from: Sven On 22 Apr 2013, at 12:29, Frank Shearar <frank.shearar(a)gmail.com> wrote: > "Sum" is usually well-defined, so I don't understand what the block's > for. With the block it's more like "take this collection, map the > values with some function, and sum the result". > > If so, it sounds like you're looking for a sugared form of > (myCollection collect: aBlock) inject: self first class zero into: #+. > ? > > (There's already Float class >> #zero and (in Squeak at least) Integer > class >> #zero, and so on. Just add MyUnit class >> #zero and you're > done.) > > frank > > On 22 April 2013 10:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I am CC-ing the pharo mailing list because it can be of interest. >> >> I agree with Guillaume that there is a legitimate need for a generic >> solution. However, at the same time we lose the convenience of simply adding >> numbers, which is likely to be the most encountered use case. >> >> I see a couple of possibilities: >> - add Collection>>sum: aBlock from: aZeroValue that takes aZeroValue as the >> default. >> - add Collection>>sumNumbers: aBlock that takes 0 as default rather than >> anyOne. >> >> What do you think? >> >> Cheers, >> Doru >> >> >> >> On Mon, Apr 22, 2013 at 10:14 AM, Guillaume Larcheveque >> <guillaume.larcheveque(a)gmail.com> wrote: >>> >>> For example, in Artefact we use Units and I have tried to use sum but it >>> doesn't works because Units doesn't allow to do 0 + 4 cm which is >>> inconsistent. >>> >>> >>> 2013/4/22 Alexandre Bergel <alexandre.bergel(a)me.com> >>>> >>>> Thanks for letting us know. I cannot see a case where having 0 as the >>>> initial value does not work as expected. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> Le 21 avr. 2013 Ã 17:35, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >>>> >>>>> Hi, >>>>> >>>>> Pharo 2.0 comes with Collection>>sum: >>>>> >>>>> Collection>>sum: aBlock >>>>> "This is implemented using a variant of the normal inject:into: >>>>> pattern. >>>>> The reason for this is that it is not known whether we're in the >>>>> normal >>>>> number line, i.e. whether 0 is a good initial value for the sum. >>>>> Consider a collection of measurement objects, 0 would be the >>>>> unitless >>>>> value and would not be appropriate to add with the unit-ed objects." >>>>> | sum sample | >>>>> sample := aBlock value: self anyOne. >>>>> sum := self inject: sample into: [ :previousValue :each | >>>>> previousValue + (aBlock value: each) ]. >>>>> ^ sum - sample >>>>> >>>>> To some extent, this is more generic than the one we had in Moose that >>>>> considered only numbers: >>>>> Collection>>sum: aSymbolOrBlock >>>>> ^ self >>>>> inject: 0 >>>>> into: [:sum :each | sum + (aSymbolOrBlock value: each)] >>>>> >>>>> >>>>> However, with the Pharo 2.0 implementation the collection must not be >>>>> empty, while the other implementation we get 0. If the collection is empty, >>>>> you get an exception due to anyOne. >>>>> >>>>> This induced several errors in metric computations (like number of >>>>> methods of a package when the package had no classes). These are now fixed, >>>>> but I thought I would let you know just in case you want to rely on this >>>>> method. >>>>> >>>>> I actually still believe we would benefit from a robust but more >>>>> limited sum:. Perhaps we could have sumNumbers:. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "If you can't say why something is relevant, >>>>> it probably isn't." >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> -- >>> Guillaume Larcheveque >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

April 22, 2013

Re: [Pharo-project] Question about AST annotation scopes order

by Marcus Denker

On Apr 22, 2013, at 1:23 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi! > > I'm taking a look at the AST annotation in > > RBProgramNode>>annotateInClass: aBehavior > self annotateInScope: (RBVariableScope > owner: (RBLiteralScope > owner: RBRootScope new > class: aBehavior) > class: aBehavior) > > With that code, the order in which variables are annotated is > > 1) inst vars > 2) literal vars (class vars, pools, globals in the environment) > 3) the root scope -> pseudo-vars (self, super, thiscontext) > > Shouldn't the order be different? Something like: > > 1) pseudo-vars (self, super, thiscontext) > 2) inst vars > 3) literal vars (class vars, pools, globals in the environment) > > So there are never conflicts, and no other scope can bind pseudo-vars? Hello, For now Opal is not using the semantic analysis of AST-Semantics but instead it's own. (it is more low-level with escaping variables and things like that). So the goal is to merge the two. What I wanted to say: No idea. :-) In Opal, self, super, thiscontex is in the Method Scope while self and super is in the Instance scope. So the lookup is temps + thisContext ivars + self + super literal vars Marcus

April 22, 2013

[Pharo-project] Question about AST annotation scopes order

by Guillermo Polito

Hi! I'm taking a look at the AST annotation in RBProgramNode>>annotateInClass: aBehavior self annotateInScope: (RBVariableScope owner: (RBLiteralScope owner: RBRootScope new class: aBehavior) class: aBehavior) With that code, the order in which variables are annotated is 1) inst vars 2) literal vars (class vars, pools, globals in the environment) 3) the root scope -> pseudo-vars (self, super, thiscontext) Shouldn't the order be different? Something like: 1) pseudo-vars (self, super, thiscontext) 2) inst vars 3) literal vars (class vars, pools, globals in the environment) So there are never conflicts, and no other scope can bind pseudo-vars? Cheers, Guille

April 22, 2013