Re: Modelling Disjoint Subtypes
Date: Mon, 26 Mar 2007 20:56:52 GMT
Message-ID: <osWNh.15577$PV3.161752_at_ursa-nb00s0.nbnet.nb.ca>
David Cressey wrote:
> "Marshall" <marshall.spight_at_gmail.com> wrote in message
> news:1174937535.353341.203170_at_p77g2000hsh.googlegroups.com...
>
>>On Mar 26, 7:18 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>>>But even if the type checking were deferred until runtime in the
>>>conditional test, the type of x and y is statically known in the block
>>>under consideration.
>>
>>THAT was the point I was trying to make.
>>
>>Regardless of how we got there, inside the block, the compiler
>>knows statically that the x and y values are integers, even
>>though their declared type in the code is rational. There can
>>exist implementations of rationals such that when the rationals
>>are integers, the generated code for a multiply is identical to
>>the generated code for multiplying integers. So within the
>>context of that block, looking at the generated code, you
>>would not be able to distinguish those two cases. The
>>types have been erased.
> > OK, now you've lost me. Why is it necessary to distinguish between the case > where x and y are integers, and the case where x and y are rationals that > are constrained to take on only integer values? > > It seems like a distinction without a difference to me.
Marshall can correct me if I am wrong: I think he was only suggesting the optimizer could use faster integer arithmetic for x and y in the block under consideration (assuming normalized rationals.)
ie. the compiler knows x and y have more specific types than their declared types within the identified block of code. Received on Mon Mar 26 2007 - 22:56:52 CEST