James

CLA's are harmful. FYI. Search that phrase on DDG and you'll see many examples.

> the amount of copy/paste makes me sad. I expect some copy-paste, that's to be expected. > during type unification Don't worry about this at the moment. I have some...

PS: Note there is also the %error stuff in parser-- that works well enough. Line numbers in the code is the goal =D

FYI: I'm currently refactoring the type unification stuff, so after that's done it will be great to revisit this and get it merged in some form. Sneak peak: The new...

Yeah, sorry for the delay. The start of that is here: https://github.com/purpleidea/mgmt/tree/feat/unification in case you're knowledgeable in this area and want to help. I'm kind of a terrible algorithmist and...

Boy has time flown by! I guess you know all the things I was busy with. In any case, unification has merged, so if you'd like to rebase this, that...

> resolver What's a resolver? > The trouble is that the error is reported at the definition of the + operator rather than the invocation. All type unification errors that...

> Okay trying to clear it up. I meant solver of course, not resolver. Duh now! I don't know why my mind missed that, lol > That is correct, but...

You want to unwrap the x.Expr part... If you see this as your error: > topLevel(func() { }): type error: int != str Then TrueCallee(_) would return: > func() {...

> the issue (in terms of AST nodes) is that this type error is reported on the ExprFunc (i.e. the declaration) of the + operator, which will never be helfpul....