On Thu, Dec 24, 2009 at 12:21 PM, Levente Uzonyi <[hidden email]> wrote:
This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all Smalltalk-80 derived Smalltalks: !Object methodsFor: 'accessing'! at: index "Answer the value of an indexable field in the receiver. Fail if the argument index is not an Integer or is out of bounds. Essential. See
documentation in Object metaclass." <primitive: 60> index isInteger ifTrue: [self errorSubscriptBounds: index]. (index isKindOf: Number)
ifTrue: [^self at: index truncated] ifFalse: [self errorNonIntegerIndex]! It is also free in the sense that the failure code is only invoked when the primitive fails and so adds nothing to the cost of successful accesses, which are the high dynamic frequency operation. It will also show up under profiling if one is concerned about efficiency, and so isn't a hidden cost.
It is also in keeping with Smalltalk's mixed mode/arbitrary precision implicit coercion number system that one *can* use fractions or floats as indices. Stripping out coercions like this will make the system more brittle. So please do *not* remove this "hack". I think it's a feature and a useful one.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Thu, 24 Dec 2009, Eliot Miranda wrote:
> > This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all Smalltalk-80 > derived Smalltalks: > > !Object methodsFor: 'accessing'! > at: index > "Answer the value of an indexable field in the receiver. Fail if the > argument index is not an Integer or is out of bounds. Essential. See > documentation in Object metaclass." > > <primitive: 60> > index isInteger > ifTrue: [self errorSubscriptBounds: index]. > (index isKindOf: Number) > ifTrue: [^self at: index truncated] > ifFalse: [self errorNonIntegerIndex]! > > It is also free in the sense that the failure code is only invoked when the > primitive fails and so adds nothing to the cost of successful accesses, > which are the high dynamic frequency operation. It will also show up under > profiling if one is concerned about efficiency, and so isn't a hidden cost. > > It is also in keeping with Smalltalk's mixed mode/arbitrary precision > implicit coercion number system that one *can* use fractions or floats as > indices. > > Stripping out coercions like this will make the system more brittle. So > please do *not* remove this "hack". I think it's a feature and a useful > one. Can you give me an example that demonstrates the usefulness of this feature? Levente _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Thu, Dec 24, 2009 at 2:52 PM, Levente Uzonyi <[hidden email]> wrote:
| a r | a := Array new: 10 withAll: 0. r := Random new. 100 timesRepeat: [| v | v := r next * 10 + 1. a at: v put: (a at: v) + 1]. a
i.e. I didn't have to provide an explicit rounding step. That's useful. But in general anywhere where an index is derived by some calculation not having to provide the rounding step could be useful/helpful/more concise. e.g. (n roundTo: 0.1) * 10 vs ((n roundTo: 0.1) * 10) asInteger.
Some thought went into the original choice. It is not a hack but there by intent. The integers are simply a subset of the reals and forcing the programmer to use them is favouring the machine above the programmer.
But I think you should justify getting rid of it rather than my having to justify keeping it. Getting rid of it risks breaking code. If it is there but does not harm then why get rid of it? best Eliot
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Levente Uzonyi-2
2009/12/25 Levente Uzonyi <[hidden email]>:
> On Thu, 24 Dec 2009, Eliot Miranda wrote: >> >> This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all Smalltalk-80 >> derived Smalltalks: >> >> !Object methodsFor: 'accessing'! >> at: index >> "Answer the value of an indexable field in the receiver. Fail if the >> argument index is not an Integer or is out of bounds. Essential. See >> documentation in Object metaclass." >> >> <primitive: 60> >> index isInteger >> ifTrue: [self errorSubscriptBounds: index]. >> (index isKindOf: Number) >> ifTrue: [^self at: index truncated] >> ifFalse: [self errorNonIntegerIndex]! >> >> It is also free in the sense that the failure code is only invoked when the >> primitive fails and so adds nothing to the cost of successful accesses, >> which are the high dynamic frequency operation. It will also show up under >> profiling if one is concerned about efficiency, and so isn't a hidden cost. >> >> It is also in keeping with Smalltalk's mixed mode/arbitrary precision >> implicit coercion number system that one *can* use fractions or floats as >> indices. >> >> Stripping out coercions like this will make the system more brittle. So >> please do *not* remove this "hack". I think it's a feature and a useful >> one. > > Can you give me an example that demonstrates the usefulness of this > feature? > > I think the right question is: - if we going to remove that, what alternative we're proposing? Like: throw a special exception class, so people may handle it and use rounding in case of need? And will it be more convenient to programmer? Less error prone? > Levente > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Eliot Miranda-2
thanks for the explanation.
I will add this in the method comment and probably class comment http://code.google.com/p/pharo/issues/detail?id=1685 Stef On Dec 25, 2009, at 1:11 AM, Eliot Miranda wrote: > > > On Thu, Dec 24, 2009 at 2:52 PM, Levente Uzonyi <[hidden email]> wrote: > On Thu, 24 Dec 2009, Eliot Miranda wrote: > > > > This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all Smalltalk-80 > > derived Smalltalks: > > > > !Object methodsFor: 'accessing'! > > at: index > > "Answer the value of an indexable field in the receiver. Fail if the > > argument index is not an Integer or is out of bounds. Essential. See > > documentation in Object metaclass." > > > > <primitive: 60> > > index isInteger > > ifTrue: [self errorSubscriptBounds: index]. > > (index isKindOf: Number) > > ifTrue: [^self at: index truncated] > > ifFalse: [self errorNonIntegerIndex]! > > > > It is also free in the sense that the failure code is only invoked when the > > primitive fails and so adds nothing to the cost of successful accesses, > > which are the high dynamic frequency operation. It will also show up under > > profiling if one is concerned about efficiency, and so isn't a hidden cost. > > > > It is also in keeping with Smalltalk's mixed mode/arbitrary precision > > implicit coercion number system that one *can* use fractions or floats as > > indices. > > > > Stripping out coercions like this will make the system more brittle. So > > please do *not* remove this "hack". I think it's a feature and a useful > > one. > > Can you give me an example that demonstrates the usefulness of this > feature? > > | a r | > a := Array new: 10 withAll: 0. > r := Random new. > 100 timesRepeat: [| v | v := r next * 10 + 1. a at: v put: (a at: v) + 1]. > a > > i.e. I didn't have to provide an explicit rounding step. That's useful. But in general anywhere where an index is derived by some calculation not having to provide the rounding step could be useful/helpful/more concise. e.g. (n roundTo: 0.1) * 10 vs ((n roundTo: 0.1) * 10) asInteger. > > Some thought went into the original choice. It is not a hack but there by intent. The integers are simply a subset of the reals and forcing the programmer to use them is favouring the machine above the programmer. > > But I think you should justify getting rid of it rather than my having to justify keeping it. Getting rid of it risks breaking code. If it is there but does not harm then why get rid of it? > > best > Eliot > > > Levente > > _______________________________________________ > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
I've put some comments in the issue #1685.
Em 25/12/2009 08:02, Stéphane Ducasse < [hidden email] > escreveu: thanks for the explanation. I will add this in the method comment and probably class comment http://code.google.com/p/pharo/issues/detail?id=1685 Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |