about consistency between hex implementations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

about consistency between hex implementations

stephane ducasse
Hi eliot

I was going over some changes and I noticed that in squeak

20 hex
        16r41
$A hex
        '41'


in pharo we have
        hex that always returns 16rXX

        $A hex '16r41'

        20 hex  '16r14'

Even if this is regular this is not really nice. In fact this ones should be fixed to return numbers and not strings.
I do not understand why hex should return a string.

and in pharo
        printStringHex the XX part only
       
$A printStringHex
        '41'

20 printStringHex
        '14'

Here this is a string since the name says it.

In VW there is asHexString which is nice too.

So could we agree on that and get a system that is nicer and more consistent.

Stef
Reply | Threaded
Open this post in threaded view
|

Re: about consistency between hex implementations

Levente Uzonyi-2
On Mon, 8 Nov 2010, stephane ducasse wrote:

> Hi eliot
>
> I was going over some changes and I noticed that in squeak
>
> 20 hex
> 16r41
> $A hex
> '41'
>
>
> in pharo we have
> hex that always returns 16rXX
>
> $A hex '16r41'
>
> 20 hex  '16r14'
>
> Even if this is regular this is not really nice. In fact this ones should be fixed to return numbers and not strings.
> I do not understand why hex should return a string.

And how? Integer >> #hex would be ^self and Character >> #hex would be
^value ?


Levente

>
> and in pharo
> printStringHex the XX part only
>
> $A printStringHex
> '41'
>
> 20 printStringHex
> '14'
>
> Here this is a string since the name says it.
>
> In VW there is asHexString which is nice too.
>
> So could we agree on that and get a system that is nicer and more consistent.
>
> Stef
>

Reply | Threaded
Open this post in threaded view
|

Re: about consistency between hex implementations

Stéphane Ducasse
In reply to this post by stephane ducasse
>>
>>
>> in pharo we have
>> hex that always returns 16rXX
>>
>> $A hex '16r41'
>>
>> 20 hex  '16r14'
>>
>> Even if this is regular this is not really nice. In fact this ones should be fixed to return numbers and not strings.
>> I do not understand why hex should return a string.
>
> And how? Integer >> #hex would be ^self and Character >> #hex would be ^value ?

It looks like I proposed something stupid :) you are right we cannot generate 16r41 as a number. I was sure that we could do that so that I do not even check.
This is strange that we cannot generate these numbers. This is strange to have things that we can only parse but not generate other than via strings.
We could have something like Integer value: 65 base: 16 that returns 16r41 and not 65 and not '16r41'
When I type 16r41 my mental perception is not that this is a string but this is a number I'm manipulating.
Like #foo, true,.... I do not think in terms of strings just objects. Now for true, #foo this is simpler because they only have one representation.
Now the fact that several objects denotes the same elementary element is just an accident. So this was fun that I could think that :).


Now my post had two topics and I would like at least to get the other fixed: consistency.

$A hex '16r41'

20 hex  '16r14'

$A printStringHex
        '41'
20 printStringHex
        '14'

Stef
Reply | Threaded
Open this post in threaded view
|

Re: about consistency between hex implementations

Eliot Miranda-2


On Mon, Nov 8, 2010 at 1:22 PM, Stéphane Ducasse <[hidden email]> wrote:
>>
>>
>> in pharo we have
>>      hex that always returns 16rXX
>>
>>      $A hex '16r41'
>>
>>      20 hex  '16r14'
>>
>> Even if this is regular this is not really nice. In fact this ones should be fixed to return numbers and not strings.
>> I do not understand why hex should return a string.
>
> And how? Integer >> #hex would be ^self and Character >> #hex would be ^value ?

It looks like I proposed something stupid :) you are right we cannot generate 16r41 as a number. I was sure that we could do that so that I do not even check.
This is strange that we cannot generate these numbers. This is strange to have things that we can only parse but not generate other than via strings.
We could have something like Integer value: 65 base: 16 that returns 16r41 and not 65 and not '16r41'
When I type 16r41 my mental perception is not that this is a string but this is a number I'm manipulating.
Like #foo, true,.... I do not think in terms of strings just objects. Now for true, #foo this is simpler because they only have one representation.
Now the fact that several objects denotes the same elementary element is just an accident. So this was fun that I could think that :).


Now my post had two topics and I would like at least to get the other fixed: consistency.

$A hex '16r41'

20 hex  '16r14'

$A printStringHex
       '41'
20 printStringHex
       '14'

+1.  The above definitions of hex are what VMMaker wants.
 
Stef

Reply | Threaded
Open this post in threaded view
|

Re: about consistency between hex implementations

Dave Mason-3
In reply to this post by Stéphane Ducasse
On Nov 8, 2010, at 16:22, Stéphane Ducasse wrote:

> This is strange that we cannot generate these numbers. This is strange to have things that we can only parse but not generate other than via strings.
> We could have something like Integer value: 65 base: 16 that returns 16r41 and not 65 and not '16r41'
> When I type 16r41 my mental perception is not that this is a string but this is a number I'm manipulating.

16r41 is a *representation* of a number, just as 10r65, 65, 2r1000001 are... and all representations of the same number.  The convention is that when numbers are displayed to use, they are in decimal, but presumably that is just an artifact from the number of fingers we have.

> Now the fact that several objects denotes the same elementary element is just an accident. So this was fun that I could think that :).

No, they're all the same object: 10r65

> Now my post had two topics and I would like at least to get the other fixed: consistency.
>
> $A hex '16r41'
>
> 20 hex  '16r14'
>
> $A printStringHex
> '41'
> 20 printStringHex
> '14'

I think those are exactly the right definitions.  Use: '16r', 20 printStringHex
if that's what you want.... otherwise, if you want to string multiple hex strings together you have to remove the 16r from each of them first.  e.g.
        '16r', 20 printStringHex, $A printStringHex

../Dave

Reply | Threaded
Open this post in threaded view
|

Re: about consistency between hex implementations

Stéphane Ducasse
In reply to this post by Stéphane Ducasse

On Nov 8, 2010, at 10:39 PM, Eliot Miranda wrote:

>
>
> On Mon, Nov 8, 2010 at 1:22 PM, Stéphane Ducasse <[hidden email]> wrote:
> >>
> >>
> >> in pharo we have
> >>      hex that always returns 16rXX
> >>
> >>      $A hex '16r41'
> >>
> >>      20 hex  '16r14'
> >>
> >> Even if this is regular this is not really nice. In fact this ones should be fixed to return numbers and not strings.
> >> I do not understand why hex should return a string.
> >
> > And how? Integer >> #hex would be ^self and Character >> #hex would be ^value ?
>
> It looks like I proposed something stupid :) you are right we cannot generate 16r41 as a number. I was sure that we could do that so that I do not even check.
> This is strange that we cannot generate these numbers. This is strange to have things that we can only parse but not generate other than via strings.
> We could have something like Integer value: 65 base: 16 that returns 16r41 and not 65 and not '16r41'
> When I type 16r41 my mental perception is not that this is a string but this is a number I'm manipulating.
> Like #foo, true,.... I do not think in terms of strings just objects. Now for true, #foo this is simpler because they only have one representation.
> Now the fact that several objects denotes the same elementary element is just an accident. So this was fun that I could think that :).
>
>
> Now my post had two topics and I would like at least to get the other fixed: consistency.
>
> $A hex '16r41'
>
> 20 hex  '16r14'
>
> $A printStringHex
>        '41'
> 20 printStringHex
>        '14'
>
> +1.  The above definitions of hex are what VMMaker wants.

Ok I will send you a cs for squeak!
Now I'm fighting with MC on something else (instead of writing a nice letter for a Phd evaluation :)


>  
> Stef
>


Reply | Threaded
Open this post in threaded view
|

Re: about consistency between hex implementations

Stéphane Ducasse
In reply to this post by Stéphane Ducasse
Hi eliot and squeakers

here is a cs with

all hex and printStringHex implementations for Squeak. Did not change the senders because no time for that.

Stef


$A hex '16r41'

20 hex  '16r14'

$A printStringHex
       '41'
20 printStringHex
       '14'







Stef

hexAndFriend.1.cs (3K) Download Attachment