Opened 6 years ago

Last modified 15 months ago

#8441 new feature request

Allow family instances in an hs-boot file

Reported by: goldfire Owned by: ezyang
Priority: normal Milestone:
Component: Compiler Version: 7.7
Keywords: backpack, TypeFamilies, hs-boot Cc: ekmett
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Compiling an .hs-boot file with a data instance leads to this error:

    Illegal family instance in hs-boot file

Yet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor declared in the instance.

Furthermore, it may sometimes be desirable to allow type family instances in a hs-boot file, as well, in case some including modules need the instance for type simplification.

Change History (11)

comment:1 Changed 5 years ago by ezyang

There is an oblique comment from chak in 2a8cdc3aee5997374273e27365f92c161aca8453 about the issue here:

                -- Check for no family instances
        ; unless (null boot_fam_insts) $
            panic ("TcRnDriver.checkHiBootIface: Cannot handle family " ++
                   "instances in boot files yet...")
            -- FIXME: Why?  The actual comparison is not hard, but what would
            --        be the equivalent to the dfun bindings returned for class
            --        instances?  We can't easily equate tycons...

In the case of type class instances, a boot interface may export a number of dictionary functions which the source file we're currently typechecking may have references to. The names of these dictionary functions are not canonical, so unlike normal exported identifiers, we can't simply take an identifier from the boot file and hope it will point to the right place. Instead, what hi-boot checking currently does is add a pile of dfun bindings to the source being typechecked, rewriting all of the booted dictionary functions to the appropriate places.

In the case of type/data families, the comment seems to reason as follows: instead of dictionary functions, the boot interface exports a file of type functions. However, these need to be equated with the real versions in the hs file. And then the comment claims we cannot easily equate tycons.

One thing to note is that while the rewriting is necessary for recursive modules, it's unnecessary if we're just interested in comparing two hi files.

comment:2 Changed 5 years ago by ezyang

Owner: set to ezyang

comment:3 Changed 5 years ago by ezyang

Keywords: backpack added

comment:4 Changed 5 years ago by goldfire

Let me know if I can be of assistance in this.

comment:5 Changed 4 years ago by thomie

Keywords: TypeFamilies added

comment:6 Changed 4 years ago by simonpj

Keywords: hs-boot added

comment:7 Changed 3 years ago by ezyang

dcoutts points out a use case for type family instances in hsig files here:

It should be easier to implement for hsig because we don't need to equate any coercions just check that the equality holds.

comment:8 Changed 19 months ago by ekmett

Cc: ekmett added

Just had this bite me as well. I have a backpack signature in which I want to state requirements about several type instances being defined.

comment:9 Changed 15 months ago by isovector

Was just bitten by this; annoyingly the associated type family instance in question is provided as a default by the typeclass.

comment:10 Changed 15 months ago by ezyang

Priority: lownormal

Bumping priority.

comment:11 Changed 15 months ago by ezyang

So, this is actually not so trivial even for Backpack. The problem is that data families turn into a rather delicate constellation of interface declarations, and the way signature merging is written, I have to teach it how to hoover these all up BACK into (deduplciated) FamInsts, so that when I write it out to an interface for the final time, everything is kosher.

Note: See TracTickets for help on using tickets.