What Happend To Tango Graphic's Package

[Christopher Wright]

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.

Well, that is a variable whose type depends on a runtime execution path. 
A polysemous type is the same value, but the type of that value can 
change based on compile time usage. Maybe on runtime usage:

---
void foo (uint i) {}
void bar (long j) {}
PolysemousIntegerType getval () { return 0; } // syntax for polysemy?

void main (char[][] args) {
    auto i = getval();
    if (args.length == 0) {
       foo(i);
    } else {
       bar(i);
    }
}

Except I don't think the auto keyword will work with polysemous types, 
at least not initially.
---

> 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.
> 
> It seems like I've got completely the wrong idea about this.

Only a little -- you can check at compile time whether there's 
ambiguity, and just issue an error if there is.

>    -- Reiner
> 

Chris Wright.