I don't normally import things qualified like that, so it hadn't occurred to me, but that makes sense. I do want to be clear that this shouldn't be sensitive to ordering, and it can occur before type checking. You just need to know what modules are importing which identifiers explicitly, and what modules are importing an unspecified set of identifiers. It should be possible to do while parsing even, as soon as you've reached a point where you know every import statement has been reached. The behaviour would thus remain the same if someone was to explicitly import the same identifier from two or more modules, since hiding the implicit imports wouldn't remove the ambiguity in that case. I'm pretty sure the code I provided is sufficient; you would just need a separate pass for qualified and unqualified imports. David Feuer wrote
You mention only unqualified imports, but if we do this, it should also apply to qualified ones:
import qualified Data.List as L import qualified MyModule as L (isInfixOf) On Oct 18, 2014 2:02 PM, "htebalaka" <
goodingm@
> wrote:
On 10/17/14 12:32, Alexander Berntsen wrote:
Maybe there are some cases today where something like this could happen, but this seems awfully, awfully implicit and hard-to-follow as a language feature.
In general I think a program that has imports like this that may clash can be automated to make it easier to manage - but ultimately such imports tend to represent a complex relationship between a module and its dependencies - I'd prefer it if these were as clear as possible. Very strong +1 from me. It seems awfully implicit and obscure for very
On 17/10/14 00:40, Austin Seipp wrote: little benefit, and it may mean quite a bit of work for tool developers.
I guess my central point is I don't see how anyone can benefit from the current behaviour. For instance, a simple real world example:
import Prelude import Data.Text.Lazy.IO (putStrLn)
Regardless of the ordering of the imports, is there any way for me to use putStrLn in any context without hiding it from the Prelude (and any other modules that I might be unintentionally importing it from)? Any unqualified use will be ambiguous, unless you hide it from every other module that might export a function with the same name. I would think the fact that it shouldn't be implicitly imported from other modules would directly follow from the fact you imported it explicitly (otherwise, why did you import it?). I'm having trouble coming up with a single example where the current behaviour is useful.
I can't speak to tooling, though I suppose if this doesn't get implemented I'll write my own. Just to be very clear, supposing you have some Import datatype which stores a list of any identifiers that are being explicitly imported unqualified (or conversely, a list of any identifiers that are being hidden), then the behaviour I'm suggesting is a pragma to enable something like this:
hide :: [Import] -> [Import] hide = flip (fmap fmap appendHiddenImports) <*> collectOnly where collectOnly :: [Import] -> [Identifier] collectOnly = concat . mapMaybe getExplicitImports appendHiddenImports :: [Identifier] -> Import -> Import getExplicitImports :: Import -> Maybe [Identifier]
where appendHiddenImports would only change import statements that import an unspecified number of unqualified identifiers, like "import X hiding (x, y)" or "import Y".
-- View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p57582... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. _______________________________________________ Glasgow-haskell-users mailing list
Glasgow-haskell-users@
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________ Glasgow-haskell-users mailing list
Glasgow-haskell-users@
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p57582... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.