On Thursday, May 14, 2015 at 5:52:18 AM UTC+10, David Gold wrote:
>
> You're welcome. My (incomplete and entirely heuristic) understanding is 
> that type inference on global variables is difficult because there aren't 
> clearly defined "boundaries" without which the variable cannot be 
> referenced. On the other hand, when manipulation of a variable is wrapped 
> in a function, the compiler knows everything that can happen to the 
> variable, since this is limited by what goes on inside the function body.
>
> I don't know if the developers are currently working on enhancing type 
> inference capabilities for global variables, but I think it is on the 
> agenda. As far as I know, there isn't any insurmountable intrinsic reason 
> why your original commands in the REPL shouldn't be able to yield an array 
> of properly inferred type. Somebody with more knowledge than I should feel 
> free to chime in. I also think that the issue has been discussed in 
> previous threads, so you can search the list for "global type inference" or 
> something like that.
>

Inference works at compile time using the set of types a name can be bound 
to.  An assignment to a name makes that set the same as the right hand 
expression's set of return types, for all execution paths after the 
assignment.  Another assignment changes the set for execution paths after 
it and so on.  The type inferred for a name depends on being able to see 
the preceeding assignments.  It does not depend on any current *value* the 
name is bound to, because at compile time the name may not have a value yet 
(locals won't and globals may not) and if it does have a value there is 
nothing to say that the *value* can't change between compilation and run 
time.
 

>
> On Wednesday, May 13, 2015 at 2:40:55 PM UTC-4, cormu...@mac.com wrote:
>>
>> Aha, yes of course. I lifted the code out of a function to inspect it 
>> more closely, and it all went downhill from there... :) 
>>
>> I can't say I really understand why there are type inference problems 
>> here, but I'm happy with the explanation. 
>>
>> Thanks!
>
>

Reply via email to