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 -
On 22.11.2014, at 14:12, Bert Freudenberg bert@freudenbergs.de 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
This is nice! Best -Tobias
Hi Bert,
On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg bert@freudenbergs.de 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.
On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Bert,
On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg bert@freudenbergs.de 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 shiftThat's funny. For me the + screams signed.
Berts made more sense to me simply because signed support negatives(-), where unsigned only support positive(+)..
Chris Muller wrote:
On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Bert,
On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg bert@freudenbergs.de 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 shiftThat'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
2014-11-23 0:56 GMT+01:00 Ben Coman btc@openinworld.com:
Chris Muller wrote:
On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Bert,
On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg bert@freudenbergs.de 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 shiftThat'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
Nicolas Cellier wrote:
2014-11-23 0:56 GMT+01:00 Ben Coman <btc@openinworld.com mailto:btc@openinworld.com>:
Chris Muller wrote: On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote: Hi Bert, On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <bert@freudenbergs.de <mailto:bert@freudenbergs.de>> 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 -benAs 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.
Eliot Miranda wrote:
Hi Bert,
On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <bert@freudenbergs.de mailto:bert@freudenbergs.de> 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 shiftThat'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 shiftBut 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
On 22.11.2014, at 17:12, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Bert,
On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <bert@freudenbergs.de mailto:bert@freudenbergs.de> 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.
I know :)
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?
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.
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.
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 -
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Bert Freudenberg -
Chris Muller -
Eliot Miranda -
Nicolas Cellier -
Tobias Pape