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

Document resolve behaviour better #92

Closed
chshersh opened this issue Jun 19, 2017 · 2 comments
Closed

Document resolve behaviour better #92

chshersh opened this issue Jun 19, 2017 · 2 comments

Comments

@chshersh
Copy link
Contributor

It's not obvious from current documentation for resolve and some universe sense how this function handles module reexports.

Consider next two Haskell modules:

module Example.Internal (details) where

details :: Int -> String
details = undefined
module Example (details) where

import           Example.Internal

There're several possibilities how exported by Example module symbols can be resolved. But not all possibilities work properly. And it's not obvious which one works and how. I've tried to experiment with them and see differences. You can observe my experiments and results here.

@phischu
Copy link
Contributor

phischu commented Jun 21, 2017

Thank you for your report. To me these results look correct and expected, but that's because I know the library :). What did surprise you?

Your code looks great perhaps we can add it as an example how to use the library and what to expect?

@chshersh
Copy link
Contributor Author

@phischu You can add my code to library documentation. It would be great!

I wasn't so surprised... Just spend some time on experimenting with library to find out whether it's possible to do desired things and if yes then how.

  1. It wasn't clear that resolve can handle reexports from other modules (I was realy glad that haskell-names can handle such situations but first I tried to resolve each module independently to make things faster instead processing all of them in single list).
  2. It's not clear that resolve handles list of Modules at once, not one by one (first, then second using information from first, then third using information from first and second). So order doesn't matter and I don't need to sort modules topologically before putting them in list.
  3. Moreover, if Internal is already in Environment then [Module l] will have access to exported symbols by current env. List (first argument) is not processed independently from env (second argument).
  4. But! According to last example in my repo — values in given Environment are not updated with elements from list.

Basically, all elements in lists can use information about each others. And they can use information from Environment but Environment doesn't use information from list of modules to update already present values. If I wrote this in some notation I would do it like this:

Module ↔ Module
Module → Environment

where arrow A → B means that A can use information from B to configure Environment properly.

chshersh added a commit to serokell/importify that referenced this issue Jun 26, 2017
phischu pushed a commit to phischu/haskell-names that referenced this issue Sep 16, 2017
mvoidex pushed a commit to mvoidex/haskell-names that referenced this issue Jan 16, 2018
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

2 participants