On 09/07/17 18:36, Ertugrul Söylemez wrote:
I mean yes, it's the same as in most OOP languages, but isn't it also bad? There must be a better way...
Is there any alternative approach to name collisions coming?
I think we should start considering what problem we're actually solving (the "record problem"), and where all solutions inevitably converge toward when it comes to name resolution: ad-hoc overloading. In particular, I think OverloadedLabels is a bad solution, and every other special-case solution is similarly going to be bad.
My opinion is and has always been: just allow type-directed name resolution in Haskell. All naming problems would go away instantly without any awkward, inconsistent extensions that need new syntax and heavy type-level machinery to work. C++ is doing it. Every OOP language is doing it. They do it, because it's useful and convenient. Let's do it, too!
AND PLEASE not the way an [existing proposal] suggests to do it! Please let's just do ad-hoc overloading. There is no reason to introduce new syntax, because syntax is completely orthogonal to this problem.
[existing proposal]: https://prime.haskell.org/wiki/TypeDirectedNameResolution
How would you propose to do TDNR instead, then? It's far from clear (to me at least) how to combine ad-hoc type-based overloading with Haskell's type inference, which is part of the reason why TDNR proposals have never been implemented. There are two basic questions that need to be answered: 1. When does an identifier get special treatment, as opposed to the usual name resolution process? 2. At what point during type inference does an ambiguous name get resolved, and what impact does that have on the type inference process? The OverloadedLabels answer to question 1 is that special identifiers get a syntactic cue (the prefix hash). It's ugly, but it's obvious that something special is happening. Similarly, the TDNR proposal uses the dot. We could say that any ambiguous identifier (i.e. one that would cause a name resolution error at present) gets special treatment, but that's rather implicit and leads to odd changes in type inference behaviour if a colliding name is brought into or removed from scope. The OverloadedLabels answer to question 2 is to use normal type class constraints to defer resolving the ambiguity to the constraint solver. This is relatively easy to specify and understand. Few alternatives have ever been properly specified (in particular, the original TDNR proposal does not really answer this question). FWIW, it has been suggested that OverloadedLabels be removed on the basis that using TypeApplications with a Symbol literal gives a not completely unreasonable syntax (fromLabel @"bar"). Note that OverloadedLabels as it currently stands does not have much interaction with records, though that might change in the future (see discussion on https://github.com/ghc-proposals/ghc-proposals/pull/6). Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/