ocharles / weeder

A re-implementation of weeder using HIE files
BSD 3-Clause "New" or "Revised" License
165 stars 27 forks source link

Dealing with implicit exports #51

Open ProofOfKeags opened 3 years ago

ProofOfKeags commented 3 years ago

Currently weeder marks everything as unused when you don't have explicit exports. It'd be nice if it was treated the same way that GHC does making everything "used" if there is no export list.

ocharles commented 3 years ago

This seems to kind of defeat the point of weeder, no? Weeder is about working out which code you didn't use, and whether or not you export it doesn't seem important for this decision. Maybe what you're looking for is to add these modules without explicit export lists to your weeder.dhall configuration with a wildcard? You can do:

{ roots = [ "^My.Module.*$" ], type-class-roots = True }

and weeder will consider everything from My.Module a root.

ProofOfKeags commented 3 years ago

Great question. One of the use cases I used weeder for back before 2.x was to detect unused package dependencies in my package.yaml/cabal files. Upon running the newest weeder I was confronted with 900 weeds resulting from exports being implicit.

I think there's a reasonable conversation to be had around whether or not this is an intentional design choice by weeder but I do find it at least unexpected that definitions GHC is treating as exported (by virtue of implicit exports) are not being treated that way by weeder.

I suppose this comes down to what the "proper" semantics of a nonexistent export list are. I see 3 possibilities:

  1. If a missing export list properly means "export all definitions", which is what I've understood it to mean to date, then I'd say that this hardly defeats the purpose of weeder at all. Sometimes I have modules with explicit exports, other times I export everything implicitly.
  2. If a missing export list properly means "export nothing", then the fact that GHC allows it seems kind of odd to me.
  3. This leaves the last possibility, which is that weeder is taking the opinionated stance that this is a GHC anti-feature, and that it is explicitly a goal to discourage its use. This is also a fine design decision but then maybe it should say that on the tin?

I'm open to discussion here, and by no means want to impose my preferences on the project, but I do think that I won't be the only one to encounter confusion around this point.

As far as XY problems go, #29 alerted me to the fact that package weed detection was put into GHC directly as of 8.10 and known to be missing in weeder. So in this case maybe what I wanted to use weeder for is not something that currently belongs in its stated set of design goals. If that is the case, then feel free to close this as "won't fix" and we can leave this thread up for posterity.

EDIT: formatting