[Newcompiler] Re: NewCompiler-ms.273.mcz

[Klaus D. Witzel]

Hi Math,

on Sat, 08 Sep 2007 14:48:18 +0200, you wrote:

> On Sep 8, 2007, at 12:39 PM, Klaus D. Witzel wrote:
>
>>> I remove the literal comparison since my InstructionCompaire dose it  
>>> implicitly.
>>> but #literalEqual: dose the same than #=:
>>>
>>> Object>>literalEqual: other
>>>
>>> 	^ self class == other class and: [self = other]
>>
>> I know, I was also puzzled at the time when I made more  
>> BytecodeGenerator methods use #literalEqual: but I agree with the  
>> initial author, since that is the best place where people can override  
>> independent of #= (and I think that a candidate for such override will  
>> be Float, partly because of Float>>#nan ;-)
>
> Now I think about it for Float>>#nan  #= don't need to be override  
> because:
>
> Float nan == Float nan -> true

I wouldn't even think about that, since from arithmetic operations the VM  
*always* returns a *new* boxed Float, say a nan with name ana, which is  
(Float nan == ana) == false but has (Float nan isNan == ana isNan) == true  
...

You already found that isNan seems to depend on primitive: 47, so only the  
VM knows, but we shouldn't care as long as isNan does give the correct  
answer :)

> So I nned to use literalEqua inside InstructionCompaire

Yes, I think so too. And also

  (self isNan == other isNan) ifTrue: [^ true]

for the Float>>#literalEqual: override :)

Cheers
Klaus

> Thanks
> 	Mth
>
> 	
>
> 	
> 		
> ___________________________________________________________________________ 
> Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son  
> interface révolutionnaire.
> http://fr.mail.yahoo.com