Missing definitions of associated types

[David Feuer]

You make a good point about people who use overlapping instances deserving
whatever they get (I'd personally love to see that whole mess removed and
replaced with something less intrusive). The bit that most severely breaks
my intuition here is that under normal, well-behaved circumstances, every
instance of a class with associated data has its own distinct associated
type(s). That is, there is a one-to-many relationship between instances and
types. When a definition is missing, that breaks, and the relationship may
become many-to-many. I suppose we may need to settle for this as long as
overlapping instances in their present form are around.

On Feb 18, 2016 12:49 PM, "Reid Barton" <rwbarton at gmail.com> wrote:

> Well, I see your point; but you also can't define a
>
> On Thu, Feb 18, 2016 at 12:00 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> It seems to be that a missing associated type definition should be an
>> error, by default, rather than a warning. The current behavior under those
>> circumstances strikes me as very strange, particularly for data families
>> and particularly in the presence of overlapping.
>>
>
>> This compiles with just a warning because Assoc Char *falls through* to
>> the general case. WAT? This breaks all my intuition about what associated
>> types are supposed to be about.
>>
>>
> Well, I see your point; but you also can't give a definition for Assoc
> Char in the Foo Char instance, because open data family instances are not
> allowed to overlap. So if failing to give a definition for an associated
> data family is an error, then it's impossible to use overlapping instances
> with classes that have associated data families. Is that your intention?
>
> I don't have a strong opinion here. I'm mildly inclined to say that people
> using overlapping instances have already signed themselves up for weird
> things happening, and we may as well let them do whatever other weird
> things they want.
>
> Regards,
> Reid Barton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160218/b6ee4924/attachment.html>