"Unknown" semantics

[soywiz]

Unknown is a special type that mutates to another type once.

For example:

var a:Array<Int> = [];

Currently is a false positive error. It says that Array can't be assigned to Array.

Also:

var a = []; // T = Unknown
a.push(10); // T = Int
a.push('test'); // Error

And:

function func(b:String -> Void) {}

func(function(param) {
// param Unknown mutates to String once to be compatible with functional type
});

I will work on this one.

[soywiz]

I have started it already:
https://github.com/Akamon/intellij-haxe/tree/UnknownSemantics

I will do a PR when it is a bit more advanced. It already handles the first case.
But still don't mutate the type. Also I will have to do some work on generics/specifics in the semantic analyzer. That hopefully will be combined and unified with the recent generics code on the resolving part. But I don't think we are in that point yet.

To keep it DRY semantic analyzer and resolver should be merged somehow. But still don't know how to properly do it. Probably when it matures a little bit more, it will be more obvious.

[soywiz]

Now I'm handling another case:

Next parts will already require generic handling. So I will work on it. I will start the PR later today.

[EBatTiVo]

To keep it DRY semantic analyzer and resolver should be merged somehow. But still don't know how to properly do it. Probably when it matures a little bit more, it will be more obvious.

Be careful not to confuse resolving with typing. The resolver doesn't and shouldn't concern itself with details such as you are describing in this issue, or the further issue of determining the current type of a dynamic variable (which completion and semantic analysis both need).

DRY is a engineering convenience, not an architectural imperative. Clear separation of responsibility is much more important than not repeating ones self.

[soywiz]

I think it is possible to reuse some logic code related to resolution in both parts. But still don't know how to. Not too important at this point. But would be great if that's the case eventually. That way body error reporting would be more consistent with what resolver says.

[soywiz]

And BTW I was thinking about that. If resolution provides the type, it will require the expression evaluator in order to determine the type of functions or fields without typetags.

function chain() { return this; }
function demo() { this.chain().ch<caret>ain().chain(); }

This for example won't work ever without the resolver working along with the expression evaluator (without the compiler that in the end is evaluating it too).

This should work already in the semantic body analyzer but doesn't work in the resolver part.

EDIT: Now I have noticed that I wrote semantic analyzer + resolver: I meant expression evaluator + resolver.
Though the expression evaluator is able to provide errors if you provide an annotator. But otherwise It would have been twice the work.

[soywiz]

I have done some code on generic resolving on the evaluation part. Soon I will be able to handle second case:

Notice that main() return type is: Int -> Int because push method having Array Int generic, is Int -> Int so it work fine.

Now I should work on changing some references to the ResultHandler that allows mutating in order to be able to update Unknowns and change the Array on array.push(XXX);

[soywiz]

Updating unknown in generics. Case 2 working. Just one more (the inline function one):

[soywiz]

Last case working. Going to create and fix tests and do the pull request:

[EBatTiVo]

@soywiz - Carlos, can this be closed or is there more work to complete it?