Opened 6 years ago

Closed 6 years ago

#8337 closed bug (invalid)

make it possible for the user to force orphanness via a module-level annotation

Reported by: errge Owned by:
Priority: normal Milestone: 7.8.1
Component: Compiler Version: 7.6.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking: #7867
Related Tickets: Differential Rev(s):
Wiki Page:


A module is marked orphan currently only in the case when we detect orphan instances, rules, type families or vectorised stuff.

In the use-case of #7867, the user will need a way to manage orphanness more directly.

When she creates an annotation (with TH or by hand), it is written to the interface file. When another file directly imports this file, it is read, everything is right. But only orphan modules are searched for transitively. So in the case of command line flags (HFlags library), where we want to transitively read all the annotations (containing info about cmdline flags) in all the imported and grandchild imported modules, we have to mark the originator modules as orphan.

This patch adds support for a special module level annotation that forces this module to be orphan.

This is the first, meaningful, but still small part of a larger work to implement #7867.

The next part will be TH support to generate annotations (not only) like this.

I'd like to make this two part of 7.8.1, if still possible; because this already makes messaging possible through adhoc datatypes+instances.

After that (probably for 7.10) we only have to make it possible to read (module) annotations back in the Q monad to have a clean solution. The laborious part of that is making module reifyable at all.

Attachments (2)

ghc-8337.patch (1.7 KB) - added by errge 6 years ago.
ghc portion
base-8337.patch (1.2 KB) - added by errge 6 years ago.
libraries/base portion

Download all attachments as: .zip

Change History (7)

Changed 6 years ago by errge

Attachment: ghc-8337.patch added

ghc portion

Changed 6 years ago by errge

Attachment: base-8337.patch added

libraries/base portion

comment:1 Changed 6 years ago by errge

Status: newpatch

comment:2 Changed 6 years ago by errge

Summary: make it possible for the user to for orphanness of an annotationmake it possible for the user to force orphanness via a module-level annotation

comment:3 Changed 6 years ago by simonpj

I'm not sure about this errge. Can't you detect orphan-ness directly?

For rules, say, a module is an orphan if it has a RULE for a function that is not defined in this module.

So for annotations, could you not say that a module is an orphan if it has annotations for entities (types, classes, functions) that are not defined in this module?

Mind you, the manual section on annotations seems to only allow annotations on things defined in this module. So then no module is an orphan.

I'm pretty confused. More information, and user documentation for this feature, would be helpful.


comment:4 in reply to:  3 Changed 6 years ago by errge

Yes, annotations are unfortunately local only.

My usecase:

  • WGet.hs imports TCP.hs
  • TCP.hs defines a commandline flag (via a template haskell function called defineFlag)
    • called tcp_connect_timeout
    • this creates a module-level annotation in B.hs, containing all the info about the flag
  • Main.hs imports WGet.hs only (doesn't import TCP.hs)
  • Main.hs's main function contains a call to the initProgram splice
    • this gathers all the flags from all the imported modules transitively
    • generates a parser
    • generates a --help output
    • at runtime run's the parser or reports the usage
  • TCP and WGet can be in different package, so different compilation unit, not one ghc --make

This assumes that Main.hs can reify annotations and module listings, but we're already working on that in #8397 and #8398.

For this to work, TCP.hs needs to be orphan, otherwise it's not read by GHC when compiling Main.hs.

Now your question: can we somehow figure this out automatically instead of depending on this hacky pragma? The only thing that gives us a clue is that there is a module annotation in TCP.hs. That's all.

So I see the following options here:

  • I change the patch to make modules orphans if they contain module annotations,
  • I change the patch to have a new type of module annotation (I'm not sure about the syntax though, because e.g. {-# ANN module orphan "String" #-} is ambiguous between orphan module annotation of "String" or module annotation of (orphan "String")),
  • I make the current approach less confusing by explicit documentation and usecase description.

In any case, I can of course add the documentation to the manual, I just wanted to get feedback as soon as possible, since we're a bit tight already for 7.8.

Now that I gave this some thought, I don't really see why would someone want to reify annotations of values and types without importing them. On the other hand, I see the use case of "orphan" module annotations, so I prefer option 1. What is your opinion?

comment:5 Changed 6 years ago by errge

Resolution: invalid
Status: patchclosed

Closing this one, as this feature request seems to be a bad idea after all.

Other possible solutions for the original problem are discussed at

Note: See TracTickets for help on using tickets.