What Happend To Tango Graphic's Package

Reiner Pope some at address.com
Tue Sep 25 00:29:13 PDT 2007


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.

It seems like I've got completely the wrong idea about this.

    -- Reiner




More information about the Digitalmars-d mailing list