Re: [Haskell-cafe] TDNR without new operators or syntax changes
Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.) 1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports); 2. And exactly one of these definitions matches the type of a (or the expected type of f if given); 3. Then this is the definition to use. That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it. This has nothing to do with ORF, which relies on magic type classes (although there is some overlap in what it can achieve). The primary use-case I had in mind is disambiguating name clashes between local and/or unqualified imports. Cross-posting to cafe and libraries as this doesn't seem to have attracted a lot of interest in users. Maybe it's just a boring proposal, maybe I didn't post it to the right list.
On Sun, 22 May 2016, Jeremy . wrote:
1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports);
2. And exactly one of these definitions matches the type of a (or the expected type of f if given);
3. Then this is the definition to use.
I know people are unhappy with Haskell's records and module system, but I still think that's because these language features are not used properly. Type classes are the tool to write generic code and reduce combinatoric explosion of functions and modules are a way to collect functions per type. Following this principle you give function names that make sense together with the module name like File.write or Channel.write. Then there is no need for the compiler to disambiguate unqualified identifiers and you keep the type and the module issues separated. Today, if you stick to the unqualified style, and I guess you want to import modules without explicit identifier list, too, then your code can break whenever the imported modules add identifiers. In order to prevent this you have to use tight package import version bounds in your Cabal file. Your proposal would not solve this problem. Type-driven name resolution may disambiguate identifiers in some case but not in all ones, thus you still need to use tight version bounds. The proposal seems to be a big complication. The compiler can no longer emit a message: "Type of function f mismatch", but it has to emit "If f means A.f, then the type error would be ..., but if it means B.f, then the type error would be ..." Or even worse: "If f means A.f and g means C.g, then the type error would be ... if f means B.f and g means C.g ... or f means A.f and g means D.g ..." The proposal also is more error-prone, because if you make a type-error this could be shadowed by a function in scope with a type that matches accidentally. A function with a very generic type and a generic name might be such an accidental match. That said, the more complicated the proposals become the more one should reconsider about whether one runs in the right direction. I think this is the case here. The simple answer could be: Switch to a cleaner coding style!
This looks like a job for nested modules. Best regards, Marcin Mrotek
participants (3)
-
Henning Thielemann -
Jeremy . -
Marcin Mrotek