On Wed, Oct 12, 2011 at 8:38 AM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 12 Oct 2011, Clara Allende wrote:
Hi guys,
I'm wondering, why?
ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
self == anObject ifTrue: [^ false] ifFalse: [^ true]
Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
^(self == anObject) not
And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^self = anObject == false
Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^(self = anObject) not.
Is there any particular reason for this that I'm missing?
Performance.
But better still is to add a ~~ primitive. I did this for VisualWorks. e.g. primitive 150 is free. why don't we use that for 1.4/4.3?
Levente
Thanks in advance!
--
"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"
Linus Torvalds
On Wed, Oct 12, 2011 at 6:44 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Wed, Oct 12, 2011 at 8:38 AM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 12 Oct 2011, Clara Allende wrote:
Hi guys,
I'm wondering, why?
ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
self == anObject ifTrue: [^ false] ifFalse: [^ true]
Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
^(self == anObject) not
And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^self = anObject == false
Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^(self = anObject) not.
Is there any particular reason for this that I'm missing?
Performance.
But better still is to add a ~~ primitive. I did this for VisualWorks. e.g. primitive 150 is free. why don't we use that for 1.4/4.3?
with or without special bytecode associated?
Levente
Thanks in advance!
--
"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"
Linus Torvalds
-- best, Eliot
On Wed, Oct 12, 2011 at 10:26 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Oct 12, 2011 at 6:44 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Wed, Oct 12, 2011 at 8:38 AM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 12 Oct 2011, Clara Allende wrote:
Hi guys,
I'm wondering, why?
ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
self == anObject ifTrue: [^ false] ifFalse: [^ true]
Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
^(self == anObject) not
And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^self = anObject == false
Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^(self = anObject) not.
Is there any particular reason for this that I'm missing?
Performance.
But better still is to add a ~~ primitive. I did this for VisualWorks. e.g. primitive 150 is free. why don't we use that for 1.4/4.3?
with or without special bytecode associated?
Initially without. Dynamic frequency is low, and primitive adds significant performance over the non-primitive version. One could use the blockCopy: special bytecode but I'd wait until doing a complete bytecode set redesign.
Levente
Thanks in advance!
--
"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"
Linus Torvalds
-- best, Eliot
-- Mariano http://marianopeck.wordpress.com
On Wed, Oct 12, 2011 at 7:29 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Wed, Oct 12, 2011 at 10:26 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Oct 12, 2011 at 6:44 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Wed, Oct 12, 2011 at 8:38 AM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 12 Oct 2011, Clara Allende wrote:
Hi guys,
I'm wondering, why?
ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
self == anObject ifTrue: [^ false] ifFalse: [^ true]
Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
^(self == anObject) not
And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^self = anObject == false
Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^(self = anObject) not.
Is there any particular reason for this that I'm missing?
Performance.
But better still is to add a ~~ primitive. I did this for VisualWorks. e.g. primitive 150 is free. why don't we use that for 1.4/4.3?
with or without special bytecode associated?
Initially without.
+1
Dynamic frequency is low, and primitive adds significant performance over the non-primitive version. One could use the blockCopy: special bytecode but I'd wait until doing a complete bytecode set redesign.
Levente
Thanks in advance!
--
"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"
Linus Torvalds
-- best, Eliot
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
OK, in the end I decided on primitive number 169. It doesn't waste the 150-159 range and is in amongst primitiveAdoptInstance and primitiveSetIdentityHash. David, would you like to integrate this into the main branch?
On Wed, Oct 12, 2011 at 10:47 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Oct 12, 2011 at 7:29 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Wed, Oct 12, 2011 at 10:26 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Oct 12, 2011 at 6:44 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Wed, Oct 12, 2011 at 8:38 AM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 12 Oct 2011, Clara Allende wrote:
Hi guys,
I'm wondering, why?
ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
self == anObject ifTrue: [^ false] ifFalse: [^ true]
Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)."
^(self == anObject) not
And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^self = anObject == false
Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object."
^(self = anObject) not.
Is there any particular reason for this that I'm missing?
Performance.
But better still is to add a ~~ primitive. I did this for VisualWorks. e.g. primitive 150 is free. why don't we use that for 1.4/4.3?
with or without special bytecode associated?
Initially without.
+1
Dynamic frequency is low, and primitive adds significant performance over the non-primitive version. One could use the blockCopy: special bytecode but I'd wait until doing a complete bytecode set redesign.
Levente
Thanks in advance!
--
"*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*"
Linus Torvalds
-- best, Eliot
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
-- Mariano http://marianopeck.wordpress.com
On Wed, Oct 12, 2011 at 11:25 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
OK, in the end I decided on primitive number 169. It doesn't waste the 150-159 range and is in amongst primitiveAdoptInstance and primitiveSetIdentityHash. David, would you like to integrate this into the main branch?
If dynamic frequency is low, why does it need to be a primitive?
Colin
On 12 October 2011 21:22, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 12, 2011 at 11:25 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
OK, in the end I decided on primitive number 169. It doesn't waste the 150-159 range and is in amongst primitiveAdoptInstance and primitiveSetIdentityHash. David, would you like to integrate this into the main branch?
If dynamic frequency is low, why does it need to be a primitive?
+1
i dont see a need for add a primitive.
Colin
On Wed, Oct 12, 2011 at 12:22 PM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 12, 2011 at 11:25 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
OK, in the end I decided on primitive number 169. It doesn't waste the 150-159 range and is in amongst primitiveAdoptInstance and primitiveSetIdentityHash. David, would you like to integrate this into
the
main branch?
If dynamic frequency is low, why does it need to be a primitive?
People avoid it because of performance. But I much prefer foo ~~ bar ifTrue: than foo == bar ifFalse:. So I suspect/hope dynamic frequency will grow as people find its not such a performance issue any more.
Colin
On Wed, Oct 12, 2011 at 1:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
People avoid it because of performance. But I much prefer foo ~~ bar ifTrue: than foo == bar ifFalse:. So I suspect/hope dynamic frequency will grow as people find its not such a performance issue any more.
Well, no accounting for taste, I guess. I'd avoid it because I much prefer foo == bar iFalse:
Colin
On Wed, Oct 12, 2011 at 1:19 PM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 12, 2011 at 1:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
People avoid it because of performance. But I much prefer foo ~~ bar
ifTrue: than foo == bar ifFalse:. So I suspect/hope dynamic frequency will grow as people find its not such a performance issue any more.
Well, no accounting for taste, I guess. I'd avoid it because I much prefer foo == bar iFalse:
But why, if it doesn't express intent directly? It's cognitively more difficult. You have to negate to get the intent.
Colin
Maybe we need an if: isAnother: method in Object....
foo if: bar isAnother: [...]
:)
- David (from iPad, typos likely)
On Oct 12, 2011, at 1:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 12, 2011 at 1:19 PM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 12, 2011 at 1:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
People avoid it because of performance. But I much prefer foo ~~ bar ifTrue: than foo == bar ifFalse:. So I suspect/hope dynamic frequency will grow as people find its not such a performance issue any more.
Well, no accounting for taste, I guess. I'd avoid it because I much prefer foo == bar iFalse:
But why, if it doesn't express intent directly? It's cognitively more difficult. You have to negate to get the intent.
Colin
-- best, Eliot
On Wed, Oct 12, 2011 at 1:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
But why, if it doesn't express intent directly? It's cognitively more difficult. You have to negate to get the intent.
<shrug> to me it's not cognitively more difficult. You have to negate either way, either "not identical" or "if false". I just prefer the negation to be explicit in the big "ifFalse:" rather than implied by the implementation of #~~.
Colin
2011/10/12 Colin Putney colin@wiresong.com:
On Wed, Oct 12, 2011 at 1:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
But why, if it doesn't express intent directly? It's cognitively more difficult. You have to negate to get the intent.
<shrug> to me it's not cognitively more difficult. You have to negate either way, either "not identical" or "if false". I just prefer the negation to be explicit in the big "ifFalse:" rather than implied by the implementation of #~~.
Colin
One of my favourites in the serie is #quo: which found currently fastest way to inline #xor:
ng := self negative == aNumber negative == false.
Nicolas
On 12.10.2011, at 22:28, Colin Putney wrote:
On Wed, Oct 12, 2011 at 1:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
But why, if it doesn't express intent directly? It's cognitively more difficult. You have to negate to get the intent.
<shrug> to me it's not cognitively more difficult. You have to negate either way, either "not identical" or "if false". I just prefer the negation to be explicit in the big "ifFalse:" rather than implied by the implementation of #~~.
Colin
Can't really say why but I also prefer "foo == bar ifFalse:" over "foo ~~ bar ifTrue:". And I don't think performance has anything to do with it. To me, "==" just seems ... simpler?
- Bert -
2011/10/13 Bert Freudenberg bert@freudenbergs.de
To me, "==" just seems ... simpler?
If one presumes that most got early on introduced to = as a symbol for equality (and ≠ for unequality and not ~), this shouldn't be too surprising?
Alex
2011/10/18 Alexander Lazarević laza@blobworks.com:
2011/10/13 Bert Freudenberg bert@freudenbergs.de
To me, "==" just seems ... simpler?
If one presumes that most got early on introduced to = as a symbol for equality (and ≠ for unequality and not ~), this shouldn't be too surprising?
Alex
Well, is ~ interpretation ubiquitous ? I rather learned ¬ NOT SIGN. http://en.wikipedia.org/wiki/Logical_not
And if ≠ is translated /= in ASCII (FORTRAN 95 & ADA) Then by analogy ~= could ambiguously mean ≃ ASYMPOTICALLY EQUAL TO and ~~ mean ≈ ALMOST EQUAL TO unless it is ≅ APPROXIMATELY EQUAL TO .
Nicolas
Nicolas,
it seems that I have failed to express myself clearly, so that you were misreading me. What I was trying to say was that I assume that most people get introduced to the symbols = and ≠ for equality and unequality early on. And that the symbol ≠ for unequality isn't (is not) ~ nor any composition that includes ~. I didn't intent to say that I assume that ~ is a very common symbol for the NOT operator and that most people learn about it as early as they learn about = and ≠.
So my gut feeling still is, that one would favor an expression that contains the most familiar = symbol (or ==) over an equivalent expression of same complexity, but that contains ~ (~= or ~~) instead, which is not as deeply rooted in our brains.
2011/10/18 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Well, is ~ interpretation ubiquitous ?
With the above it's hopefully no surprise that I think it's not.
I rather learned ¬ NOT SIGN. http://en.wikipedia.org/wiki/Logical_not
Same here, but over the years I also saw !x, bar below x, bar above x, dot below x and even dot above x ... meaning NOT.
And if ≠ is translated /= in ASCII (FORTRAN 95 & ADA) Then by analogy ~= could ambiguously mean ≃ ASYMPOTICALLY EQUAL TO and ~~ mean ≈ ALMOST EQUAL TO unless it is ≅ APPROXIMATELY EQUAL TO .
Alex
2011/10/19 Alexander Lazarević laza@blobworks.com:
Nicolas,
it seems that I have failed to express myself clearly, so that you were misreading me. What I was trying to say was that I assume that most people get introduced to the symbols = and ≠ for equality and unequality early on. And that the symbol ≠ for unequality isn't (is not) ~ nor any composition that includes ~. I didn't intent to say that I assume that ~ is a very common symbol for the NOT operator and that most people learn about it as early as they learn about = and ≠.
Nice case of misinterpretation indeed! My failure...
Nicolas
So my gut feeling still is, that one would favor an expression that contains the most familiar = symbol (or ==) over an equivalent expression of same complexity, but that contains ~ (~= or ~~) instead, which is not as deeply rooted in our brains.
2011/10/18 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Well, is ~ interpretation ubiquitous ?
With the above it's hopefully no surprise that I think it's not.
I rather learned ¬ NOT SIGN. http://en.wikipedia.org/wiki/Logical_not
Same here, but over the years I also saw !x, bar below x, bar above x, dot below x and even dot above x ... meaning NOT.
And if ≠ is translated /= in ASCII (FORTRAN 95 & ADA) Then by analogy ~= could ambiguously mean ≃ ASYMPOTICALLY EQUAL TO and ~~ mean ≈ ALMOST EQUAL TO unless it is ≅ APPROXIMATELY EQUAL TO .
Alex
On 10/12/2011 22:20, Eliot Miranda wrote:
On Wed, Oct 12, 2011 at 1:19 PM, Colin Putney <colin@wiresong.com mailto:colin@wiresong.com> wrote:
On Wed, Oct 12, 2011 at 1:16 PM, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > People avoid it because of performance. But I much prefer foo ~~ bar ifTrue: than foo == bar ifFalse:. So I suspect/hope dynamic frequency will grow as people find its not such a performance issue any more. Well, no accounting for taste, I guess. I'd avoid it because I much prefer foo == bar iFalse:But why, if it doesn't express intent directly? It's cognitively more difficult. You have to negate to get the intent.
It's really the same either way. My main reason for disliking ~= and ~~ is that both of these are aesthetically unpleasing. I'd much rather see <> instead of ~= and perhaps <==> instead of ~~.
Cheers, - Andreas
2011/10/13 Andreas Raab andreas.raab@gmx.de:
On 10/12/2011 22:20, Eliot Miranda wrote:
On Wed, Oct 12, 2011 at 1:19 PM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 12, 2011 at 1:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
People avoid it because of performance. But I much prefer foo ~~ bar ifTrue: than foo == bar ifFalse:. So I suspect/hope dynamic frequency will grow as people find its not such a performance issue any more.
Well, no accounting for taste, I guess. I'd avoid it because I much prefer foo == bar iFalse:
But why, if it doesn't express intent directly? It's cognitively more difficult. You have to negate to get the intent.
It's really the same either way. My main reason for disliking ~= and ~~ is that both of these are aesthetically unpleasing. I'd much rather see <> instead of ~= and perhaps <==> instead of ~~.
Yes, one could think that ~= is approximately equal... Though the operator means different in Matlab too.
<> exists in some languages too (Ada ? Fortran 95). But I dislike <==> <<>> or <><> or =<>= are not better...
I like =/= but that makes a single selector... =//= ?
Unless we start using what unicode provides (Fortress).
Nicolas
Cheers, - Andreas
2011/10/13 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
2011/10/13 Andreas Raab andreas.raab@gmx.de:
On 10/12/2011 22:20, Eliot Miranda wrote:
On Wed, Oct 12, 2011 at 1:19 PM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 12, 2011 at 1:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
People avoid it because of performance. But I much prefer foo ~~ bar ifTrue: than foo == bar ifFalse:. So I suspect/hope dynamic frequency will grow as people find its not such a performance issue any more.
Well, no accounting for taste, I guess. I'd avoid it because I much prefer foo == bar iFalse:
But why, if it doesn't express intent directly? It's cognitively more difficult. You have to negate to get the intent.
It's really the same either way. My main reason for disliking ~= and ~~ is that both of these are aesthetically unpleasing. I'd much rather see <> instead of ~= and perhaps <==> instead of ~~.
Yes, one could think that ~= is approximately equal... Though the operator means different in Matlab too.
<> exists in some languages too (Ada ? Fortran 95).
Ah no, it is /= <> was in Matrix-x Xmath for example...
But I dislike <==> <<>> or <><> or =<>= are not better...
I like =/= but that makes a single selector... =//= ?
Unless we start using what unicode provides (Fortress).
Nicolas
Cheers, - Andreas
On Wed, Oct 12, 2011 at 11:25:32AM -0700, Eliot Miranda wrote:
OK, in the end I decided on primitive number 169. It doesn't waste the 150-159 range and is in amongst primitiveAdoptInstance and primitiveSetIdentityHash. David, would you like to integrate this into the main branch?
Aside from preferences concerning use of #~~ is there any serious objection to adding the primitive itself? I can think of no reason not to do so, and have added it to the main branch on that basis. If anyone can think of a good reason that it should not be there, I'll remove it.
Dave
vm-dev@lists.squeakfoundation.org
-
Alexander Lazarević -
Andreas Raab -
Bert Freudenberg -
Colin Putney -
David T. Lewis -
David Ungar -
Eliot Miranda -
Igor Stasenko -
Mariano Martinez Peck -
Nicolas Cellier