Value Preservation and Polysemy

[Max Samukha]

On Fri, 28 Nov 2008 16:08:06 -0800, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:

>I've had a talk with Walter today, and two interesting things transpired.
>
>First off, Walter pointed out that I was wrong about one conversion rule 
>(google value preservation vs. type preservation). It turns out that 
>everything that's unsigned and less than int is actually converted to 
>int, NOT unsigned int as I thought. This is the case in C, C++, and D.
>
>Second, as of today Walter devised a very crude heuristic for 
>typechecking narrowing conversions:
>
>(a) a straight assignment x = y fails if y is wider than x.
>
>(b) however, x = e compiles for more complex expressions EVEN if there 
>is potential for loss of precision.
>
>Now enter polysemy. With that, we can get the right rules in place and 
>minimize false positives. An expression will yield a polysemous value 
>with the as-C-does-it type as its principal type. The secondary type is 
>a carefully computed narrower type that is the tightest actual type.
>
>If you just say auto or use the value with overloaded functions etc., 
>it's just like in C - the as-in-C type will be in vigor. But if you 
>specifically ask for a narrower type, the secondary type enters in effect.
>
>Examples:
>
>uint u1 = ...;
>ushort us1 = ...;
>auto a = u1 & us1; // fine, a is uint
>ushort b = u1 & us1; // fine too, secondary type kicks in
>
>long l1 = ...;
>auto c = u1 / l1; // c is long
>int d = u1 / l1; // fine too, secondary type kicks in
>
>We need to think this through for complex expressions etc. Walter and I 
>are quite excited that this will take care of a significant portion of 
>the integral conversions mess (in addition to handling literals, 
>constants, and variables within a unified framework).
>
>The plan is to deploy polysemous integrals first without changing the 
>rest of the conversion rules. At that point, if the technique turns out 
>to enjoy considerable success, Walter agreed to review and possibly 
>stage in the change I suggested to drop the implicit signed -> unsigned 
>conversion. With that, I guess we can claim victory in the war between 
>spurious vs. too lax conversions.
>
>I'm very excited about polysemy. It's entirely original to D, covers a 
>class of problems that can't be addressed with any of the known 
>techniques (subtyping, coercion...) and has a kick-ass name to boot. 
>Walter today mentioned he's still not sure I hadn't made "polysemy" up. 
>Indeed, Thunderbird and Firefox are suggesting it's a typo - please "add 
>to dictionary" :o).
>

I think it's a very relevant term. Given that type of a value attaches
a meaning to that value, values getting different types (meanings)
depending on the context are polysemous. Very cool.

>
>Andrei