Overlapping and incoherent instances

[Andreas Abel]

@Johan: imho, your question does make sense.

Say I am issueing a library with

   instance Bla Char
   instance Bla a => Bla [a]

   instance Blubb Char
   instance Blubb String

then, by the proposed distinction, the user of my library would have to 
write

   instance {-# OVERLAPPING #-} Bla String

but

   instance {-# OVERLAPPABLE #-} Blubb a => Blubb [a]

I would not know why the user has to be burdened with such quibbles.  A 
simple

   instance {-# OVERLAP #-} Bla String
   instance {-# OVERLAP #-} Blubb a => Blubb [a]

to shut off the compiler complaining about non-unique solutions 
involving these *additional* instance would do the job.

The semantics would be:  Whenever an instance adds *new* ambiguities, it 
has to be marked with OVERLAP.

And, there should be monotonicity such that the user can mark any 
instance as OVERLAP even though there is no actual overlap (otherwise 
things become mad when switching import ordering etc.).


On 30.07.2014 14:55, Johan Tibell wrote:
> On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic
> <ivan.miljenovic at gmail.com> wrote:
>> On 30 July 2014 22:07, Andreas Abel <andreas.abel at ifi.lmu.de> wrote:
>>> I am a bit surprised by the distinction you outline below.  This is maybe
>>> because I am native German, not English.  The German equivalent of
>>> "overlap", "überschneiden/überlappen", is used exclusively in a symmetrical
>>> fashion.  It's like in English, if I say "our interests overlap", then it is
>>> pointless to ask whether my interest are overlapping yours or are overlapped
>>> by yours.  I want to alert you to the fact that non-native English speaker
>>> might have little understanding for a distinction between "OVERLAPPING" and
>>> "OVERLAPPABLE".
>>>
>>> Let's try to guess what it meant:  Given
>>>
>>> A) instance Bla Char
>>> B) instance Bla a => Bla [a]
>>> C) instance Bla String
>>>
>>> you will in context A,B write C as OVERLAPPING,
>>> and in context A,C write B as OVERLAPPABLE?
>>
>> IIUC, B will be OVERLAPPABLE ("you can overlap this") and C will be
>> OVERLAPPING ("I'm overlapping an existing one") whereas C will be
>> plain.
>
> Apologies if this question doesn't make sense.
>
> Can we really talk about overlapping, given that instances can be
> written in different modules, moved between modules, or removed?
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/