Re: Modelling Disjoint Subtypes

David Cressey wrote:

> "Marshall" <marshall.spight_at_gmail.com> wrote in message
> news:1174856101.649290.231830_at_p77g2000hsh.googlegroups.com...
>

>>On Mar 25, 11:53 am, "David Cressey" <cresse..._at_verizon.net> wrote:
>>
>>>"Marshall" <marshall.spi..._at_gmail.com> wrote in message
>>>
>>>>As an aside, there exists systems in which the storage cost
>>>>*at runtime* for type information is zero, because the types
>>>>exist only at compile time, and are completely removed
>>>>after.
>>>
>>>If you are saying what I think you are saying, then I disagree.
>>>
>>>For example,  let's I have
>>>   float x, a, b;
>>>   x= a + b
>>>
>>>If I look at the variables x, a, and b at runtime, the type is gone.

>>>I look at the code generated by the compiler, I'm going to find that the
>>>plus sign is represented by a floating point addition operation.  So, to

>>>extent that operator indicates type of operand,  the information is

>>>there at runtime, although buried in the code.
>>>
>>>This could be important if you were writing a decompiler.
>>
>>It seems pretty clear we agree on what is actually happening.
>>However there may be some disagreement on what terminology
>>best describes that.
>>
>>It hinges on your phrase: "to the extent that the operator indicates
>>the type ..." The example you picked is one where the operators
>>are actually supported in the CPU itself. This is a fairly unusual
>>case. The "extent" may not be all that much in the usual case.

But floating point might only be a representation of the type or even a part of the type. The knowledge of the exact type might be spread among many different operations.

>>Since numbers are on my mind lately, let's consider rationals
>>and integers. Suppose we have some rational numbers x and y.
>>Further suppose we do some thing if they are integers and
>>something else otherwise.
>>
>>  if (isInt(x) and isInt(y) {
>>    // consider the code here
>>  } else { ... }
>>
>>Now, inside the first pair of braces, we know *statically*
>>that the denominator of both x and y is 1. So if we multiply
>>x and y, the compiler, which ordinarily would be doing
>>two multiplies (x.numerator * y.numerator,
>>x.denominator * y.denominator) may well throw the second
>>multiply away, since its result is a constant 1. So if
>>you looked at the generated code, you'd see only one
>>multiply and possibly falsely conclude that x and y are
>>integer.

I am not sure I follow. Doesn't the code above constrain x and y exactly as you mention in the region marked for consideration?

>>Or consider an example with float representations of Fahrenheit
>>and Celsius as two different types. If the types are erased,
>>and we want to compare two temperatures to see which one
>>is higher, in both cases they will be identical unadorned floats;
>>the distinction between F and C is gone.

If one were to follow the analogy fully, one would have to consider both kilograms and pounds-mass. Received on Mon Mar 26 2007 - 15:06:58 CEST