Manuel M T Chakravarty wrote:
> 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.
The iface representation always contains the parent, only the
pretty-printing is affected (see pprExport in LoadIface). This is why
I'm concerned that you think this invariant is necessary. Perhaps that
hack in pprExport is just confusing and should be removed.
I worry about this because it's another invariant that we have to
manually maintain, and those are generally worth eliminating, or
exposing explicitly in the type. If it turns out that you need to
extract the parent from an AvailInfo a lot, then perhaps the
representation should be
AvailInfo name = AvailTC name Bool [name]
Where the Bool says whether the parent is included or not.
I wonder whether in the presence of the now-more-complex relationships
between entities we should revisit AvailInfo anyway; it makes sense for
single level relationships, but perhaps not for the two-level
relationships we now have.
> 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.
I don't understand - if two GlobalRdrElts represent the same Name, then
shouldn't their parents be the same?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
