TDNR without new operators or syntax changes

[AntC]

> Dan Doel <dan.doel <at> gmail.com> writes:
> 
>> On Thu, May 26, 2016 at 5:14 AM, Peter <voldermort <at> hotmail.com> wrote:
>> Solving for everything but f, we get f :: T -> Int.
> 
> So TDNR happens for things in function position (applied to something).

Before we get carried away, TDNR doesn't happen at all.
You're speculating about what might be able to happen?
 
> > Solving for everything but f, we get f :: T -> Int.
> 
> So TDNR happens for things in argument position.

[By "things" there you mean functions.]

TDNR as originally spec'd wouldn't try to solve this.
(Because there's no dot-postfix invocation.)
And my reading of DuplicateRecordFields is that won't either.

There's a good reason. We're trying to solve for record field accessors.
So unlike Dan's examples, there's a bunch of same-named functions:
personId :: T -> Int
personId :: U -> Int
personId :: V -> Int

personId's are always Ints. There's no point trying to work 'outside in',
because it won't disambiguate anythng.

> > May not be solvable, would fail to disambiguate.
> 
> But there's exactly one combination of f and v definitions that will
> succeed with the right type. So why doesn't that happen?

Because in general you have to run the whole of type inference
to solve this case.
(That's Peter's step 2. in his earlier message.)
But we can't run type inference until we've disambiguated all names.
Chicken and egg.

> ... Another way to phrase the question is: why would
> TDNR only disambiguate based on argument types of functions
> and not on return types? ...

Because, per above, the return types are all the same
(for same-named field accessors).

> ... Is it doing backtracking search?
> How do you add backtracking search to GHC's inference algorithm? Etc.

No GHC does not now do backtracking search.
No it couldn't be somehow bolted on.
There's no guarantee that adding backtracking
could resolve any more cases that can be solved now,
because now we have hugely powerful inference honed for decades,
and type system design to exploit it.

> ... And type classes fix that by
> turning overloading into something that happens via an agreed upon
> interface, with declared conventions, and which can be abstracted over
> well. ...

Yes, so the full program for ORF is to make 'Magic Type Classes'
seem to the type inferencer like regular class-based overloading.

> But also, for something as far reaching as doing TDNR for every
> ambiguous name, it's not terribly clear to me what a good algorithm
> even is, unless it's only good enough to handle really simple
> examples, and just doesn't work most of the time ...

DuplicateRecordFields is aiming for the simple examples.
If some case isn't simple enough,
you can always add signatures until it is.


AntC