TDNR without new operators or syntax changes

[Evan Laforge]

As long as were back on this topic again (sort of), and just to
satisfy my curiousity, what would happen if you tried to do records
just like C structs?  So e.g. a•b requires 'a' to be a record with a
'b' field, and is just one identifier, no functions involved, and 'b'
is not a separate value.

I could see how people might think it was not powerful enough or not
very idiomatic, but is there something about haskell that would make
it just not work?

I didn't see that option on the increasingly all-encompassing Records wiki page.

On Fri, May 27, 2016 at 10:33 PM, AntC <anthony_clayden at clear.net.nz> wrote:
>> 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
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users