On Wed, Oct 12, 2011 at 8:38 AM, Levente Uzonyi <[hidden email]> wrote:
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?
best, Eliot |
On Wed, Oct 12, 2011 at 6:44 PM, Eliot Miranda <[hidden email]> wrote:
with or without special bytecode associated?
-- Mariano http://marianopeck.wordpress.com |
On Wed, Oct 12, 2011 at 10:26 AM, Mariano Martinez Peck <[hidden email]> wrote:
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.
best, Eliot |
On Wed, Oct 12, 2011 at 7:29 PM, Eliot Miranda <[hidden email]> wrote:
+1
-- Mariano http://marianopeck.wordpress.com |
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 <[hidden email]> wrote:
best, Eliot primitiveNotIdentical.st (43K) Download Attachment |
On Wed, Oct 12, 2011 at 11:25 AM, Eliot Miranda <[hidden email]> 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 <[hidden email]> wrote: > > On Wed, Oct 12, 2011 at 11:25 AM, Eliot Miranda <[hidden email]> 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 > -- Best regards, Igor Stasenko. |
In reply to this post by Colin Putney-3
On Wed, Oct 12, 2011 at 12:22 PM, Colin Putney <[hidden email]> 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.
best, Eliot |
On Wed, Oct 12, 2011 at 1:16 PM, Eliot Miranda <[hidden email]> 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 <[hidden email]> wrote:
But why, if it doesn't express intent directly? It's cognitively more difficult. You have to negate to get the intent.
best, Eliot |
Maybe we need an if: isAnother: method in Object.... foo if: bar isAnother: [...] :) - David (from iPad, typos likely)
|
In reply to this post by Eliot Miranda-2
On Wed, Oct 12, 2011 at 1:20 PM, Eliot Miranda <[hidden email]> 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 <[hidden email]>: > > On Wed, Oct 12, 2011 at 1:20 PM, Eliot Miranda <[hidden email]> 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 |
In reply to this post by Eliot Miranda-2
On 10/12/2011 22:20, Eliot Miranda wrote:
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 |
In reply to this post by Colin Putney-3
On 12.10.2011, at 22:28, Colin Putney wrote: > On Wed, Oct 12, 2011 at 1:20 PM, Eliot Miranda <[hidden email]> 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 - |
In reply to this post by Andreas.Raab
2011/10/13 Andreas Raab <[hidden email]>: > > On 10/12/2011 22:20, Eliot Miranda wrote: > > On Wed, Oct 12, 2011 at 1:19 PM, Colin Putney <[hidden email]> wrote: >> >> On Wed, Oct 12, 2011 at 1:16 PM, Eliot Miranda <[hidden email]> 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 <[hidden email]>: > 2011/10/13 Andreas Raab <[hidden email]>: >> >> On 10/12/2011 22:20, Eliot Miranda wrote: >> >> On Wed, Oct 12, 2011 at 1:19 PM, Colin Putney <[hidden email]> wrote: >>> >>> On Wed, Oct 12, 2011 at 1:16 PM, Eliot Miranda <[hidden email]> 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 >> >> >> > |
In reply to this post by Eliot Miranda-2
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 |
In reply to this post by Bert Freudenberg
2011/10/13 Bert Freudenberg <[hidden email]>
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ć <[hidden email]>: > > 2011/10/13 Bert Freudenberg <[hidden email]> >> >> 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 |
Free forum by Nabble | Edit this page |