What Happend To Tango Graphic's Package

[Don Clugston]

Reiner Pope wrote:
> Don Clugston wrote:
>> Christopher Wright wrote:
>>> Janice Caron wrote:
>>>> On 9/24/07, Chad J <gamerChad at _spamisbad_gmail.com> wrote:
>>>>> I hope polysemous types come out and solve this mess.
>>>>
>>>> What does "polysemous type" mean? What are polysemous types?
>>
>> For example, the literal number 1. Could be a short, int, uint, float, 
>> complex number,...
>> Strict typing forces us to assign a type to it, but actually they're 
>> all the same.
>>
>>>
>>> A variable that can have several types depending on how it is 
>>> assigned or casted is polysemous. Walter wants to use this especially 
>>> for string literals -- should it be fixed length or not, should it be 
>>> char, wchar, dchar?
>>
>> It should kill signed/unsigned type mismatches forever, too.
>> It's really a fantastic concept.
> 
> Can someone explain how it works?
> 
>  From the slides, I can make a few guesses about it, but none of them 
> seems to fit with everything on the slides.
> 
> Guess #1: it's a form of type inference which is more powerful than 
> "auto" because it examines use as well as the initial assignment.
> 
> A number of other languages do this, and it's very nice, but it seems 
> not to gel with the statement, "if it is used in a context where sign 
> does matter ... then an error is issued."
> 
> Guess #2: algebraic data types/discriminating unions/some other fancy name.
> 
> The example, "function results (polysemous: result type or error type)" 
> suggests this. In Haskell syntax, this might be the type,
> 
> data FunctionResult = Result Int | Error String
> 
> so the result is a union of a string and an int; pattern matching is 
> used to check if it's an result or an error.
> 
> However, this doesn't seem to relate to the rest of the examples.
> 
> ---
> 
> My concern is that, unless it is a form of type inference, I can't see a 
> context where uint and int behave identically: for instance, they 
> overflow at different places. If that's the case, then a specific 
> semantics must be chosen (ie int over uint, or uint over int), and the 
> polysemous-ness no longer exists.


They behave identically in cases like:

int a = 7;
uint b = 3;

What's the type of (a|b) ?
Is it int, or uint?
So only one of the following two cases is OK; the other has a signed-unsigned 
type mismatch:

int c = a|b;
uint d = a|b;

And it's completely arbitrary which one is allowed.
But this is stupid; actually, it doesn't matter. The same asm code is generated, 
regardless. Static type checking is a nuisance in this case.