On Wed, Aug 5, 2015 at 9:55 AM, Oliver Charles
It makes me sad if we can't progress the language on the grounds that people's attempts at parsing the source code themselves would break. If you want to know all the imports, then we should be providing this information through tools for people to consume.
It's not whether or not there's a tool, there already is. It's that the tool must be more complicated. For example, we can get imports from haskell-src-exts but it has bugs, it can be out of date, and it's slower. Or ghc -M... which doesn't have those problems. So maybe it's not really a serious objection.
On the other hand, lots of languages have a "local open" feature like this. I think many of them make you first import the module, and then you can "open" it in a local scope. This would address both my "parse the whole file for imports" objection and the "what about instances", because module importing would be unchanged.
Indeed, this could be a path forward. I'm not really familiar with any languages that do this, could you link to some examples of how this works in other languages?
I was thinking of agda.. though it's only from memory so I could be wrong. Or perhaps it was cayenne... one of those dependently typed languages models modules as records, and then has syntax to dequalify record access. Rust has a full-on nested module system, but I seem to recall you have to declare a link dependency on an external crate ("import"), and then separately import the symbols from it ("use").