On 21.11.2014, at 23:01, Eliot Miranda uploaded VMMaker.oscog-eem.950.mcz > > Introduce >>> as an explicitly signed shift. Ugh, can we pick something else, please? It's really confusing. In various languages (notably Java and JavaScript), >> is signed and >>> unsigned. I don't know any language that has both operators and the meaning reversed. And >> still means signed or unsigned depending on context. Not nice at all. How about ... >> signed/unsigned depending on type (what we have now) >>+ force unsigned shift >>- force signed shift - Bert - smime.p7s (5K) Download Attachment |
On 22.11.2014, at 14:12, Bert Freudenberg <[hidden email]> wrote: > On 21.11.2014, at 23:01, Eliot Miranda uploaded VMMaker.oscog-eem.950.mcz >> >> Introduce >>> as an explicitly signed shift. > > Ugh, can we pick something else, please? It's really confusing. In various languages (notably Java and JavaScript), >> is signed and >>> unsigned. I don't know any language that has both operators and the meaning reversed. > > And >> still means signed or unsigned depending on context. Not nice at all. > > How about ... > > >> signed/unsigned depending on type (what we have now) > >>+ force unsigned shift > >>- force signed shift Best -Tobias signature.asc (1K) Download Attachment |
In reply to this post by Bert Freudenberg
Hi Bert,
On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email]> wrote:
This is confused because of history. What I'd like is to use >> as a signed shift (because that's what it is) and >>> as an unsigned shift. And I'd like to change bitShift: to generate signed shifts and introduce unsignedBitShift: and ditch signedBitShift:. But that means changing all uses of >> in VMMaker. This would be my preferred solution but I think its *really* important that if we go this route we change VMMaker.oscog, VMMaker and VMMakerJS at the same time. Can we synchronise this?
Right. And there's the signedBitShift: bogosity too.
That's funny. For me the + screams signed. So I would accept >> signed/unsigned depending on type (what we have now) >>+ force signed shift>>- force unsigned shift But I don't think you're right about >> being context dependent. At least in VMMaker.oscog >> is always unsigned. The change I made to generation was to not coerce a 64-bit receiver to 32-bits, but I didn't change the signedness. best,
Eliot |
On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda <[hidden email]> wrote: > > Hi Bert, > > On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email]> wrote: >> >> >> On 21.11.2014, at 23:01, Eliot Miranda uploaded VMMaker.oscog-eem.950.mcz >> > >> > Introduce >>> as an explicitly signed shift. >> >> Ugh, can we pick something else, please? It's really confusing. In various languages (notably Java and JavaScript), >> is signed and >>> unsigned. I don't know any language that has both operators and the meaning reversed. > > > This is confused because of history. What I'd like is to use >> as a signed shift (because that's what it is) and >>> as an unsigned shift. And I'd like to change bitShift: to generate signed shifts and introduce unsignedBitShift: and ditch signedBitShift:. But that means changing all uses of >> in VMMaker. This would be my preferred solution but I think its *really* important that if we go this route we change VMMaker.oscog, VMMaker and VMMakerJS at the same time. Can we synchronise this? > > >> >> >> And >> still means signed or unsigned depending on context. Not nice at all. > > > Right. And there's the signedBitShift: bogosity too. > >> >> >> How about ... >> >> >> signed/unsigned depending on type (what we have now) >> >>+ force unsigned shift >> >>- force signed shift > > > That's funny. For me the + screams signed. Berts made more sense to me simply because signed support negatives(-), where unsigned only support positive(+).. |
In reply to this post by Eliot Miranda-2
Eliot Miranda wrote: > > > > ------------------------------------------------------------------------ > > Hi Bert, > > On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email] > <mailto:[hidden email]>> wrote: > > > On 21.11.2014, at 23:01, Eliot Miranda uploaded > VMMaker.oscog-eem.950.mcz > > > > Introduce >>> as an explicitly signed shift. > > Ugh, can we pick something else, please? It's really confusing. In > various languages (notably Java and JavaScript), >> is signed and > >>> unsigned. I don't know any language that has both operators and > the meaning reversed. > > > This is confused because of history. What I'd like is to use >> as a > signed shift (because that's what it is) and >>> as an unsigned shift. > And I'd like to change bitShift: to generate signed shifts and introduce > unsignedBitShift: and ditch signedBitShift:. But that means changing > all uses of >> in VMMaker. This would be my preferred solution but I > think its *really* important that if we go this route we change > VMMaker.oscog, VMMaker and VMMakerJS at the same time. Can we > synchronise this? > > > > > And >> still means signed or unsigned depending on context. Not nice > at all. > > > Right. And there's the signedBitShift: bogosity too. > > > > How about ... > > >> signed/unsigned depending on type (what we have now) > >>+ force unsigned shift > >>- force signed shift > > > That's funny. For me the + screams signed. So I would accept > > >> signed/unsigned depending on type (what we have now) > >>+ force signed shift > >>- force unsigned shift > > But I don't think you're right about >> being context dependent. At > least in VMMaker.oscog >> is always unsigned. The change I made to > generation was to not coerce a 64-bit receiver to 32-bits, but I didn't > change the signedness. > > -- > best, > Eliot The use of both + and - still leaves room for ambiguity. How about... >>> force unsigned >>+ force signed cheers -ben |
In reply to this post by Chris Muller-3
Chris Muller wrote: > > On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda <[hidden email]> wrote: >> Hi Bert, >> >> On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email]> wrote: >>> >>> On 21.11.2014, at 23:01, Eliot Miranda uploaded VMMaker.oscog-eem.950.mcz >>>> Introduce >>> as an explicitly signed shift. >>> Ugh, can we pick something else, please? It's really confusing. In various languages (notably Java and JavaScript), >> is signed and >>> unsigned. I don't know any language that has both operators and the meaning reversed. >> >> This is confused because of history. What I'd like is to use >> as a signed shift (because that's what it is) and >>> as an unsigned shift. And I'd like to change bitShift: to generate signed shifts and introduce unsignedBitShift: and ditch signedBitShift:. But that means changing all uses of >> in VMMaker. This would be my preferred solution but I think its *really* important that if we go this route we change VMMaker.oscog, VMMaker and VMMakerJS at the same time. Can we synchronise this? >> >> >>> >>> And >> still means signed or unsigned depending on context. Not nice at all. >> >> Right. And there's the signedBitShift: bogosity too. >> >>> >>> How about ... >>> >>> >> signed/unsigned depending on type (what we have now) >>> >>+ force unsigned shift >>> >>- force signed shift >> >> That's funny. For me the + screams signed. > > Berts made more sense to me simply because signed support > negatives(-), where unsigned only support positive(+).. > Revising my previous suggestion... >>> force unsigned >>- force signed cheers -ben |
In reply to this post by Eliot Miranda-2
I know :)
We might, but this would still break plugins that are not in the VMMaker repo. That was one of my thoughts with leaving >> alone and defining two new ones for explicit signed/unsigned shift.
That would be great, and I didn’t check thoroughly - maybe I’m mixing it up with bitShift:, which certainly depends on the types? If we pick two new operators, I quite like Ben’s idea (>>> and >>-). And if you’re sure that >> is unsigned in oscog then it should be trivial to replace with (the proposed unsigned) >>>. Which we then could also implement in Smalltalk to do an unsigned shift if the receiver happens to be negative (it just needs to figure out the word length - I can think of some hacks to do that). - Bert - smime.p7s (5K) Download Attachment |
In reply to this post by Ben Coman
2014-11-23 0:56 GMT+01:00 Ben Coman <[hidden email]>:
As a latin, writing the most significant bit to least significant from left to right, and the sign leftmost, I would suggest ->> to suggest how we propagate the minus sign bit... Nicolas |
Nicolas Cellier wrote: > > > > ------------------------------------------------------------------------ > > > > 2014-11-23 0:56 GMT+01:00 Ben Coman <[hidden email] > <mailto:[hidden email]>>: > > > Chris Muller wrote: > > On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda > <[hidden email] <mailto:[hidden email]>> wrote: > > Hi Bert, > > On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg > <[hidden email] <mailto:[hidden email]>> wrote: > > > On 21.11.2014, at 23:01, Eliot Miranda uploaded > VMMaker.oscog-eem.950.mcz > > Introduce >>> as an explicitly signed shift. > > Ugh, can we pick something else, please? It's really > confusing. In various languages (notably Java and > JavaScript), >> is signed and >>> unsigned. I don't know > any language that has both operators and the meaning > reversed. > > > This is confused because of history. What I'd like is to > use >> as a signed shift (because that's what it is) and >>> > as an unsigned shift. And I'd like to change bitShift: to > generate signed shifts and introduce unsignedBitShift: and > ditch signedBitShift:. But that means changing all uses of > >> in VMMaker. This would be my preferred solution but I > think its *really* important that if we go this route we > change VMMaker.oscog, VMMaker and VMMakerJS at the same > time. Can we synchronise this? > > > > And >> still means signed or unsigned depending on > context. Not nice at all. > > > Right. And there's the signedBitShift: bogosity too. > > > How about ... > > >> signed/unsigned depending on type (what we > have now) > >>+ force unsigned shift > >>- force signed shift > > > That's funny. For me the + screams signed. > > > Berts made more sense to me simply because signed support > negatives(-), where unsigned only support positive(+).. > > > Revising my previous suggestion... > >>> force unsigned > >>- force signed > > cheers -ben > > > As a latin, writing the most significant bit to least significant from > left to right, and the sign leftmost, I would suggest ->> to suggest how > we propagate the minus sign bit... > > Nicolas Interesting point. |
Free forum by Nabble | Edit this page |