Skip to content
This repository has been archived by the owner on Apr 25, 2020. It is now read-only.

Add 'imported-from' command. #823

Open
wants to merge 36 commits into
base: master
Choose a base branch
from
Open

Add 'imported-from' command. #823

wants to merge 36 commits into from

Conversation

DanielG
Copy link
Owner

@DanielG DanielG commented Aug 9, 2016

No description provided.

@DanielG DanielG added this to the v5.7.0.0 milestone Aug 9, 2016
@carlohamalainen
Copy link
Collaborator

So I'm right to clone the main repo and push directly to this branch?

@DanielG
Copy link
Owner Author

DanielG commented Aug 9, 2016

Yeah, you can just add this repo as a remote to your existing repo though, no need to re-clone.

@lierdakil
Copy link
Collaborator

WRT tests, I should probably tweak test code so it fails early, but here's an actual problem:

>>>> Cabal errors begin
Warning: /home/travis/build/DanielG/ghc-mod/ghc-mod.cabal: Ignoring unknown
section type: custom-setup
cabal: Could not resolve dependencies:
trying: ghc-mod-5.6.0.0 (user goal)
trying: base-4.8.2.0/installed-0d6... (dependency of ghc-mod-5.6.0.0)
next goal: haddock-api (dependency of ghc-mod-5.6.0.0)
rejecting: haddock-api-2.17.3, 2.17.2, 2.16.1, 2.16.0 (conflict: ghc-mod =>
haddock-api<2.16)
rejecting: haddock-api-2.15.0.2, 2.15.0.1, 2.15.0 (conflict:
base==4.8.2.0/installed-0d6..., haddock-api => base>=4.3 && <4.8)
Dependency tree exhaustively searched.
<<<< Cabal errors end

@lierdakil
Copy link
Collaborator

Okay, 7.10 fixed. 7.8 is still failing, in part due to test files not compiling under 7.8 (f.ex. ImportedFrom03.hs has some instance-related fails), and in part I honestly don't know why, but it throws GMENoVisibleExports.

@carlohamalainen
Copy link
Collaborator

The failures on 7.8.4 are my fault, have reproduced them on my laptop. I'll look into it.

@carlohamalainen
Copy link
Collaborator

@DanielG I've gone through all your comments, happy for final review now.

@DanielG
Copy link
Owner Author

DanielG commented Aug 27, 2016

I'm doing a cleanup pass right now so don't bother fixing any of the things I'm about to comment on. Those are just FYI.

refineAs (MySymbolUserQualified userQualSym) exports = filterM f exports
where
-- f :: ModuleExports -> Bool
f export = case modas of
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I replaced this entire function with modAs == moduleOfQualifiedName userQualSym. Don't you think a datatype called MySymbolUserQualified should maintain the invariant that the module it contains is actually qualified ;)

The way we deal with this usually is by using smart constructors (mkSymbolUserQualified etc.) that check this invariant and only use those to construct that type. (optionally moving the type definition to a separate module that doesn't export the constructor so the mkFun in the only way to make a value of that type.

refineRemoveHiding exports =
map (\e -> e { qualifiedExports = removeHiding e }) exports
where
removeHiding export = filter (`notElem` hiding') thisExports
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thisExports :: [FullyQualifiedName] but hiding' :: [QualifiedName], those will never match AFAIU. The type system could've saved you here. Next time use it :p

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm nevermind, but I just realized the whole parsing below is completely pointless. Just keeping more information by making FullyQualifiedName a record is much easier.

@lierdakil
Copy link
Collaborator

I think at this point this is "good enough". I could probably refine this ad infinum given the chance, but I think I have to stop at some point, and this particular point seems as good as any.

@DanielG, if you could review this, that would be cool.

@DanielG
Copy link
Owner Author

DanielG commented Oct 26, 2016

Looks good, though we had a mode to just print the package+module name instead of the full haddock path (see comments following #810 (comment)) . @lierdakil did you remove that?

Also we seem to have reverted to using error to report user facing errors which we fixed before, see fa1417a for example.

@lierdakil
Copy link
Collaborator

Looks good, though we had a mode to just print the package+module name instead of the full haddock path (see comments following #810 (comment)) . @lierdakil did you remove that?

Yep, missed that bit. I basically reimplemented the whole deal from scratch while stealing bits and pieces from @carlohamalainen's implementation when appropriate, so I was bound to miss something.

Although I should point out that while hackage url can be, in general, inferred from package id, module and symbol, local haddock path can not, and current implementation prefers the latter if it's available. So there's that. I think we can solve this problem in another way though, see below.

Also we seem to have reverted to using error to report user facing errors which we fixed before, see fa1417a for example.

Reason being, those errors never leave the scope of the function, so my reasoning was that why define exceptions that are local to the module. Now that I think about it, I should probably make it throw GME exceptions and handle those downstream, since it might be more useful to library users. Sorry, didn't think about that -- was OD'ing on caffeine at the time, so I kinda rushed a bit.

Also while on the topic of library users. I've been bitching about library interface for a while (#696), and now seems as good a time as any to start imposing at least some structure on the returned values. So what do you think about returning [ImportedFromResult] instead of String? We can make an instance of TextOutput ImportedFromResult (and also TextOutput a => TextOutput [a]) to convert that to String in ghc-mod binary. Also we can dump the whole batch of information out, including package name and hackage url here, without having to pass a ton of flags to the function itself (we could instead add those into TextOutput instances -- e.g. by defining an instance-specific output config)
Thoughts?

@DanielG
Copy link
Owner Author

DanielG commented Oct 26, 2016

Returning proper datatypes instead of strings sounds lovely actually I don't see why we shouldn't.

carlohamalainen added a commit to carlohamalainen/ghcmod-vim that referenced this pull request Aug 14, 2017
@carlohamalainen
Copy link
Collaborator

I updated this PR against the master branch but I'm not seeing any status from travis - is there something else that I have to do?

@DanielG
Copy link
Owner Author

DanielG commented Aug 14, 2017

We've stopped using travis a while ago. The builds are now on Gitlab(CI) but it looks like the repo mirroring has broken, I'm looking into that. If you have a gitlab account I can add you there so you can push this branch to the other repo as well, which will trigger a build.

FYI you can actually configure git to push to multiple repos at once when you push to a remote, see https://gist.github.com/bjmiller121/f93cd974ff709d2b968f

@carlohamalainen
Copy link
Collaborator

Just made an account: https://gitlab.com/carlohamalainen

@DanielG
Copy link
Owner Author

DanielG commented Aug 15, 2017

Done

@DanielG DanielG modified the milestones: v5.9.0.0, Whenever Sep 14, 2017
@DanielG
Copy link
Owner Author

DanielG commented Sep 14, 2017

@carlohamalainen are you still working on this? Do you need help with the new CI setup or something?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants