Simon Marlow:
> [EMAIL PROTECTED] wrote:
> > Fri Oct 20 20:58:29 PDT 2006 Manuel M T Chakravarty <[EMAIL PROTECTED]>
> > * Fix parent position in RnNames.nubAvails
> > - `RnNames.nubAvails', which amalgamates AvailInfo items that belong to
> > the
> > same parent, needs to be careful that the parent name occurs first if
> > it is
> > in the list of subnames at all. (Otherwise, we can get funny export
> > items
> > in ifaces.)
> >
> > - I discovered this while debugging family import/exports, but I am
> pretty
> > sure the bug would also have shown up without using families under the
> > right circumstances.
>
> I'm interested - what goes wrong if the parent doesn't occur first? I
> noticed
> that it often didn't when I was working on this code. I checked and it was
> the
> same in 6.4.2, so I assumed it must be ok, and I didn't encounter any
> problems
> except that the pretty-printing code had to print out the parent name.
If it isn't first, then the parent is not removed from the subnames when
the AvailInfo is converted into its iface representation; ie, we get
things like "C{foo, C, T}" in the iface. I am not sure whether there
are any bad consequences from this, other than confusing --show-iface
output, without type families. With type families, you can get
RdrName.GlobalRdrElt values that when combined with RdrName.plusParent
trigger the assertion in plusParent, when reading ifaces with these
funny export items.
Manuel
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
