SPJ: you go to the bottom of the page. In the dropdown menu you select "Add Reviewers". I just added kosmikus already though.

@ezyang, perhaps the package key or some similar identifier also needs to be included here?

I'm happy to review this next week, once I'm back from holidays.

I wrote some comments for specific lines, but actually I think I have a problem with the general philosophy of this patch. For one, adding the original module name is insufficient, because with package qualified imports I can get two identifiers in scope with the same module name but different package keys.

But more generally, it seems like the prefix should be based on the QUALIFIED name of the import (if it exists), or no prefix if it doesn't; this will be guaranteed to uniquely identify it, and is a lot more meaningful if this output shows up user-side.

@ezyang, Using qualified names sounds good, I'll try to implement that.

How is this going, @osa1? Can I be of any help?

I'm waiting for comments from @kosmikus and/or @dreixel for the current approach and qualified names idea.

I was waiting for @ezyang to reply back on the changes after his comment.

OK, I wasted quite a lot of time trying to figure out how can I get qualified names of types from DerivSpecs. My plan was to get it in TcDeriv.tcDeriving and propagate it further to the code that generates new data types for ConstructorName and DataType instances(TcGenGenerics.genGenericMetaTyCons). I feel like this is possible, because tcDeriving generated instances already use these qualified names(for example, it generates instance Show Blah.Name where ... if I have import M as Blah). Any help would be appreciated.

Hey @osa1, if using the qualified names is a lot of work, maybe we can just continue to use the full names (the error messages will just be worse.)

I don't know if it's a lot of work, it's just that I'm lost in the API and I feel like an experienced person could tell us how to do that(or that it's not possible to do) in 5 seconds.

By full names do I presume you mean the current approach?

We discussed this on IRC and I want to keep this thread up-to-date.

The problem is, given a TyCon we need to generate a name unique to the module that the TyCon is imported from. (this should take package imports into account)

A TyCon has a Unique, Name, Kind and Arity and none of these help.

I tried using PrintUnqualified data, but the qualified names it gives us are module names. E.g. if I have "import A.B as C" it gives me "A.B" and not "C". So it doesn't solve the problem with package imports.

RdrName has all we need, but they're eliminated in the process of renaming. So if we want to use RdrNames we need to somehow propagate it from renamer to type checker, which is a lot of work. Alternatively, we can add one more field to Name for RdrNames. That's also a lot of work because Names are used everywhere, and bgamari and ezyang didn't like this idea.

That's where I got stuck.

I am "an experienced person" but I'm totally lost in all this generics stuff. If you'd like me to help I'll need more context.

Can you give a minimal, concrete example, giving

• The source code
• The code that is currently generated from it
• What the problem with the generated code is
• How you would like to fix it if you could only get hold of the relevant info

Please do hat on the ticket, not buried her in Phab.

Then I'll look when I get back from holiday.

Maybe Andres will too.

Thanks

Simon

@osa1, is this ready for a review?

Yes!

Sorry for the delay, I'll address the comments once I return from ICFP.

@bgamari, how does it look?
@bgamari, do you know any ways to add a test with multiple packages? I was hoping to add a regression test.

ping @bgamari, @austin.

@osa1, sorry for the delay! I was pulled away from GHC things for the last week or so.

This now looks quite good. @ezyang, any final thoughts?

@austin, All done.

Should this be moved to "landing" stage? (I don't want to forget this and then have to rebase)