Re: Modelling Disjoint Subtypes
Date: Mon, 26 Mar 2007 15:18:19 GMT
Message-ID: <%uRNh.15483$PV3.159434_at_ursa-nb00s0.nbnet.nb.ca>
David Cressey wrote:
> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> news:SzPNh.15446$PV3.158860_at_ursa-nb00s0.nbnet.nb.ca...
>
>>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. >>> >>>But if >>> >>> >>>>>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
>
>>>the >>> >>> >>>>>extent that operator indicates type of operand, the information is >>> >>>still >>> >>> >>>>>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. >>> >>>This isn't quite true. In the case of a CPU that doesn't support
>
> floating
>
>>>point arithmetic, >>>(e.g. Intel 8086) the "operator" I'm referring to could be a call to
>
> the
>
>>>floating point addition subroutine. In the case of a Java compiler,
>
> the
>
>>>"operator" could be anything that's supported in the operator
>
> repertoire of
>
>>>the JVM. It still gives the clue that the operands "must" be floating
>
> point
>
>>>numbers. >> >>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.
>
> agreed.
>
>
>>>>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.
>>>
>>>A compiler generates code based on static analysis. If the compiler
>>>generated code fails to multiply the denominators, there are only two
>>>possibilities: either x and y are somehow constrained to only take on
>>>integer values, or a run time error (possibly undetected) will occur,
>
> when
>
>>>one of them violates the isInt constraint. >> >>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?
>
> Yes, I guess so, if the if clause is part of the compiled code.
> But in such a case, the actual type testing is being deferred to run time.
I don't necessarily agree that it is deferred. Certainly, many languages defer such checking; however, Marshall was discussing languages where type information is handled statically during the compilation stage with no type information available at runtime. Or am I confusing two threads?
> In this case, your earlier comments about typing of literal values apply.
In the example provided, isInt(x) is itself a boolean literal. Is it not? Then again, wouldn't that always make one branch of the conditional dead code?
>>>>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. >>> >>>Units of measure is a separable issue. For the case you present, The
>
> Unit
>
>>>of measure can be considered a linear equation. It's complicated in the >>>case of temperature, because temperature does not inherently have ratio. >>>[long pseudo scientific rant about absolute zero snipped by the original >>>author]. Let's take something like mass 123.45 Kilograms can be taken
>
> as a
>
>>>ratio: namely the ratio between 123.45 and the mass of a one kilogram >>>object. If the mass is given as a rational (e.g. 12345/100) that
>
> doesn't
>
>>>change anything. You can cascade the ratios. >> >>If one were to follow the analogy fully, one would have to consider both >>kilograms and pounds-mass.
>
> Technically, a pound is a unit of force, not mass. The "slug" is the unit
> of mass in the English system, but most people use the pound as if it were
> a unit of mass. The number of kilograms in a given sample of moon rocks
> does not change when it is transported from the Moon to the eaarth. The
> number of pounds does.
I did not specify pounds but pounds-mass, which is likewise unaffected by transport to other satellites. At the same time, if I transported my bathroom scale to the moon, it would likewise misrepresent my mass even though the scale is marked in kg.
If we were to use slugs on the FPS side, we should use metric slugs or mugs on the SI side. Canada switched from Imperial to SI when I was nine after I had already learned most imperial measures and while I was still young enough to easily internalize other measures. That pretty-much makes me "bilingual" when it comes to units of measure.
We could choose newtons and slog-rods per fortnight squared as our types, but to address the original example we need two types. As you mentioned, units of measure are generally related by some function or equation (probably linear.) In the system Marshall describes, the code for comparing the values would necessarily embody that equation thereby revealing at least something about the types.
Was that what you were trying to say? Received on Mon Mar 26 2007 - 17:18:19 CEST