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_clay...@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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
