Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idris export rules inflate namespaces, Haskell rules do no. Why ? #111

Closed
nicolabotta opened this issue Nov 30, 2012 · 5 comments
Closed

Comments

@nicolabotta
Copy link

The Haskell program

> module MA where
> type A = Bool
> module MB where
> import MA
> type B = A
> module TestExport where
> import MB
> i :: A -> B
> i = not

does not type check because, in |TestExport|, |A| is not visible. If one wants to use |MA.A| in |TestExport|, one has to import |MA|. This is good: if the names imported by a module were automatically injected in the namespaces of its clients, name clashes would hardly be avoidable. Maintaining and refactoring programs would be a nightmare: in order to find out the modules a program might depend upon, one would have to backwards reconstruct the whole import tree. In contrast, the Idris program

> module MA
> A : Set
> A = Bool
> module MB
> import MA
> B : Set
> B = A
> module TestExport
> import MB
> i : A -> B
> i = not

type checks. This suggests that the export rules of Idris might be fundamentally different from those of Haskell. Is this the case ? Why ?

@edwinb
Copy link
Contributor

edwinb commented Dec 3, 2012

Hmm, I haven't really thought so much about import/export rules. It is to do with the way import works, which I know to be broken in some (easily fixable) ways.

I'll have a think about how to do it properly, though I probably can't do it very quickly. The behaviour you're seeing is definitely wrong.

@nicolabotta
Copy link
Author

Maybe it is not a problem if names which are defined in modules which
are imported by imported modules are resolved and can be addressed
without full qualification.

But I think in this case the programmer needs some form of control.
Maybe a "-noautoexport" or a user settable "nameresolutiondepth" ?

Edwin Brady notifications@github.com wrote:

Hmm, I haven't really thought so much about import/export rules. It is
to do with the way import works, which I know to be broken in some
(easily fixable) ways.

I'll have a think about how to do it properly, though I probably can't
do it very quickly. The behaviour you're seeing is definitely wrong.


Reply to this email directly or view it on GitHub.
[Xa8jSg8hAG_XCIX7_YoUpRXz5UHBHTwiX9khz7iuyV7CyTEXymXfI42r0PdrtUxJ.gif]

@edwinb edwinb closed this as completed in 7b5f4aa Dec 13, 2014
@edwinb
Copy link
Contributor

edwinb commented Dec 13, 2014

The default is now that imported modules are not automatically reexported, and you need to say "import public A" if that's the behaviour you want (which is exactly the old behaviour). This might break a few things, but I think the new way is better, and what you were looking for.

Sorry to take 2 years over this. At least it's evidence I get back to things eventually :).

@david-christiansen
Copy link
Contributor

This is wonderful!

@nicolabotta
Copy link
Author

Edwin Brady notifications@github.com wrote:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 14 Dec 2014 16:03:59 +0100
Message-ID: 20943.1418569439@cirrus.gutzkowa.net

The default is now that imported modules are not automatically
reexported, and you need to say "import public A" if that's the
behaviour you want (which is exactly the old behaviour). This might
break a few things, but I think the new way is better, and what you
were looking for.

Thanks a lot Edwin, this is great news ! Best, Nicola

Sorry to take 2 years over this. At least it's evidence I get back to
things eventually :).


Reply to this email directly or view it on GitHub.*

Fcc: +outbox
Subject: Re: [Idris-dev] Idris export rules inflate namespaces, Haskell rules do no. Why ? (#111)
In-reply-to: idris-lang/Idris-dev/issues/111/66884545@github.com
References: idris-lang/Idris-dev/issues/111@github.com idris-lang/Idris-dev/issues/111/66884545@github.com
Comments: In-reply-to Edwin Brady notifications@github.com
message dated "Sat, 13 Dec 2014 09:47:35 -0800."

X-Mailer: MH-E 8.3; nmh 1.5; GNU Emacs 23.4.1

msmorgan pushed a commit to msmorgan/Idris-dev that referenced this issue Aug 28, 2017
Fixes idris-lang#111
Previously, if a module B imports a module A, then a module C imports B,
the public names in A would also be visible to C (i.e. B would
automatically reexport everything from A). This seems to be a bad
default.

This patch changes the default behaviour so that the only names exported
from a module are those defined in that module. If B imports A and wants
to reexport everything in A, then A should be imported with the "public"
modifier (i.e. "import public A").

Several changes have been made to the prelude, since several prelude
modules were taking advantage of the old broken behaviour.

This may cause lots of things to break. Sorry. The fix is typically just
to import the module you should have imported anyway :).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants