Overlapping and incoherent instances

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Overlapping and incoherent instances

Simon Peyton Jones

Friends

One of GHC’s more widely-used features is overlapping (and sometimes incoherent) instances.  The user-manual documentation is here.

The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: OverlappingInstances and IncoherentInstances respectively.

However the overlap/incoherent-ness is a property of the *instance declaration* itself, and has been for a long time.  Using LANGUAGE OverlappingInstances simply sets the “I am an overlapping instance” flag for every instance declaration in that module.

This is a Big Hammer.  It give no clue about *which* particular instances the programmer is expecting to be overlapped, nor which are doing the overlapping.    It brutally applies to every instance in the module.  Moreover, when looking at an instance declaration, there is no nearby clue that it might be overlapped.  The clue might be in the command line that compiles that module!

Iavor has recently implemented per-instance-declaration pragmas, so you can say

instance {-# OVERLAPPABLE #-} Show a => Show [a] where …

instance {-# OVERLAPPING #-} Show [Char] where …

This is much more precise (it affects only those specific instances) and it is much clearer (you see it when you see the instance declaration).

This new feature will be in GHC 7.10 and I’m sure you will be happy about that.  But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and IncoherentInstances, as way to encourage everyone to use the new feature instead of the old big hammer.  The old LANGUAGE pragmas will continue to work, of course, for at least another complete release cycle.  We could make that two cycles if it was helpful.

However, if you want deprecation-free libraries, it will entail a wave of library updates.

This email is just to warn you, and to let you yell if you think this is a bad idea.   It would actually not be difficult to retain the old LANGUAGE pragmas indefinitely – it just seems wrong not to actively push authors in the right direction.

These deprecations of course popped up in the test suite, so I’ve been replacing them with per-instance pragmas there too.  Interestingly in some cases, when looking for which instances needed the pragmas, I found…none. So OverlappingInstances was entirely unnecessary.  Maybe library authors will find that too!

Simon


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Niklas Hambüchen
Hi Simon,

> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …

Is the syntax somewhat flexible in where the pragma can be placed?
For example, some might prefer

  {-# OVERLAPPING #-}
  instance Show [Char] where …
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Herbert Valerio Riedel
On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …
>
> Is the syntax somewhat flexible in where the pragma can be placed?
> For example, some might prefer
>
>   {-# OVERLAPPING #-}
>   instance Show [Char] where …

This variant may also be more convenient in cases where you need to
CPP-guard that pragma, as it's on a separate line.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Johan Tibell-2
On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel <[hidden email]> wrote:

> On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
>>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …
>>
>> Is the syntax somewhat flexible in where the pragma can be placed?
>> For example, some might prefer
>>
>>   {-# OVERLAPPING #-}
>>   instance Show [Char] where …
>
> This variant may also be more convenient in cases where you need to
> CPP-guard that pragma, as it's on a separate line.

Agreed, and if we remove the old pragma (even with a deprecation
cycle) you'll see quite a few of those as many library authors try to
have their libraries compile with the last 3 major GHC versions.

P.S. For e.g. INLINABLE we require that you mention the function name
next to the pragma (which means that you can e.g. put the pragma after
the declaration). What's the rationale to not require

{-# OVERLAPPING Show [Char] #-}

here? Perhaps it's too annoying to have to repeat the types?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Overlapping and incoherent instances

Simon Peyton Jones
The current implementation requires the pragma exactly where showed it.

I'm not keen on allowing it to be separated.

I suppose with some more parser jiggery pokery it could be allowed immediately before (or, better, after).

But cpp would let you say

instance
#if blah
  {-# OVERLAPPABLE #-}
#endif
  Show a => Show [a] where ...

Simon

| -----Original Message-----
| From: Johan Tibell [mailto:[hidden email]]
| Sent: 29 July 2014 11:02
| To: Herbert Valerio Riedel
| Cc: Niklas Hambüchen; Haskell Libraries ([hidden email]); GHC
| users; Simon Peyton Jones; ghc-devs
| Subject: Re: Overlapping and incoherent instances
|
| On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel <[hidden email]>
| wrote:
| > On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
| >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …
| >>
| >> Is the syntax somewhat flexible in where the pragma can be placed?
| >> For example, some might prefer
| >>
| >>   {-# OVERLAPPING #-}
| >>   instance Show [Char] where …
| >
| > This variant may also be more convenient in cases where you need to
| > CPP-guard that pragma, as it's on a separate line.
|
| Agreed, and if we remove the old pragma (even with a deprecation
| cycle) you'll see quite a few of those as many library authors try to
| have their libraries compile with the last 3 major GHC versions.
|
| P.S. For e.g. INLINABLE we require that you mention the function name
| next to the pragma (which means that you can e.g. put the pragma after
| the declaration). What's the rationale to not require
|
| {-# OVERLAPPING Show [Char] #-}
|
| here? Perhaps it's too annoying to have to repeat the types?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Richard Eisenberg-2
I think one nice thing about this proposal is that it doesn't seem (to me) to require CPP around the pragma: unrecognized pragmas are warned about but are otherwise harmless. Are folks very keen to have *warning-free* compilation on several GHC versions? Personally, I would aim for warning-free compilation on a most recent version, and otherwise successful compilation on older versions.

The only place CPP would be needed is around the LANGUAGE pragma, in order to avoid the deprecation warning in 7.10.

One other issue this brings up: how does this all interact with -XSafe? Right now, Safety can be inferred by looking at the set of LANGUAGE pragmas and the import list. (Right?) With the change as implemented, Safe inference would require looking at all instance declarations. Is this OK?

Richard

On Jul 29, 2014, at 7:02 AM, Simon Peyton Jones <[hidden email]> wrote:

> The current implementation requires the pragma exactly where showed it.
>
> I'm not keen on allowing it to be separated.
>
> I suppose with some more parser jiggery pokery it could be allowed immediately before (or, better, after).
>
> But cpp would let you say
>
> instance
> #if blah
>  {-# OVERLAPPABLE #-}
> #endif
>  Show a => Show [a] where ...
>
> Simon
>
> | -----Original Message-----
> | From: Johan Tibell [mailto:[hidden email]]
> | Sent: 29 July 2014 11:02
> | To: Herbert Valerio Riedel
> | Cc: Niklas Hambüchen; Haskell Libraries ([hidden email]); GHC
> | users; Simon Peyton Jones; ghc-devs
> | Subject: Re: Overlapping and incoherent instances
> |
> | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel <[hidden email]>
> | wrote:
> | > On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
> | >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …
> | >>
> | >> Is the syntax somewhat flexible in where the pragma can be placed?
> | >> For example, some might prefer
> | >>
> | >>   {-# OVERLAPPING #-}
> | >>   instance Show [Char] where …
> | >
> | > This variant may also be more convenient in cases where you need to
> | > CPP-guard that pragma, as it's on a separate line.
> |
> | Agreed, and if we remove the old pragma (even with a deprecation
> | cycle) you'll see quite a few of those as many library authors try to
> | have their libraries compile with the last 3 major GHC versions.
> |
> | P.S. For e.g. INLINABLE we require that you mention the function name
> | next to the pragma (which means that you can e.g. put the pragma after
> | the declaration). What's the rationale to not require
> |
> | {-# OVERLAPPING Show [Char] #-}
> |
> | here? Perhaps it's too annoying to have to repeat the types?
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Andreas Abel
In reply to this post by Niklas Hambüchen
+1. I like Niklas' syntax better.  Also OVERLAPPABLE is a horrible word,
OVERLAPPING sound less formidable (even though it might be slightly less
accurrate).

On 29.07.2014 11:29, Niklas Hambüchen wrote:
>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …
>
> Is the syntax somewhat flexible in where the pragma can be placed?
> For example, some might prefer
>
>    {-# OVERLAPPING #-}
>    instance Show [Char] where …

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

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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Brandon Allbery
On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <[hidden email]> wrote:
+1. I like Niklas' syntax better.  Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate).

We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Krzysztof Skrzętnicki

How about CAN_OVERLAP?

--
Krzysztof

29-07-2014 15:40, "Brandon Allbery" <[hidden email]> napisał(a):
On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <[hidden email]> wrote:
+1. I like Niklas' syntax better.  Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate).

We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Andreas Abel
Or just OVERLAP
(applying the razor).

On 29.07.2014 17:56, Krzysztof Skrzętnicki wrote:

> How about CAN_OVERLAP?
>
> --
> Krzysztof
>
> 29-07-2014 15:40, "Brandon Allbery" <[hidden email]
> <mailto:[hidden email]>> napisał(a):
>
>     On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         +1. I like Niklas' syntax better.  Also OVERLAPPABLE is a
>         horrible word, OVERLAPPING sound less formidable (even though it
>         might be slightly less accurrate).
>
>
>     We already get "overlap ok" in instance-related type errors, so
>     OVERLAP_OK wouldn't be particularly alien even if it doesn't quite
>     fit in with existing pragmas.
>
>     --
>     brandon s allbery kf8nh                               sine nomine
>     associates
>     [hidden email] <mailto:[hidden email]>
>     [hidden email] <mailto:[hidden email]>
>     unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
>
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://www.haskell.org/mailman/listinfo/libraries
>


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

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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Overlapping and incoherent instances

Simon Peyton Jones
In reply to this post by Krzysztof Skrzętnicki

CAN_OVERLAP and CAN_BE_OVERLAPPED?

 

(instead of OVERLAPPING and OVERLAPPABLE)

 

Or CAN-OVERLAP, CAN-BE-OVERLAPPED

 

That’s ok with me if that’s what you all want!

 

Simon

 

From: Glasgow-haskell-users [mailto:[hidden email]] On Behalf Of Krzysztof Skrzetnicki
Sent: 29 July 2014 16:56
To: Brandon Allbery
Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries ([hidden email]); ghc-devs
Subject: Re: Overlapping and incoherent instances

 

How about CAN_OVERLAP?

--
Krzysztof

29-07-2014 15:40, "Brandon Allbery" <[hidden email]> napisał(a):

On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <[hidden email]> wrote:

+1. I like Niklas' syntax better.  Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate).

 

We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas.

 

--

brandon s allbery kf8nh                               sine nomine associates

[hidden email]                                  [hidden email]

unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Overlapping and incoherent instances

Simon Peyton Jones
In reply to this post by Richard Eisenberg-2
| One other issue this brings up: how does this all interact with -XSafe?
| Right now, Safety can be inferred by looking at the set of LANGUAGE
| pragmas and the import list. (Right?) With the change as implemented,
| Safe inference would require looking at all instance declarations. Is
| this OK?

I'm honestly not sure, but I do know that, in the implementation, each instance declaration keeps track of (a) whether it is OVERLAPPABLE/OVERLAPPING/INCOHERENT, and (b) the setting of -XSafe in the module where the instance declaration is given.

This doesn't change.  So I can't answer your question directly, but I think that the behaviour is unchanged from that at present.

Simon

|
| Richard
|
| On Jul 29, 2014, at 7:02 AM, Simon Peyton Jones <[hidden email]>
| wrote:
|
| > The current implementation requires the pragma exactly where showed
| it.
| >
| > I'm not keen on allowing it to be separated.
| >
| > I suppose with some more parser jiggery pokery it could be allowed
| immediately before (or, better, after).
| >
| > But cpp would let you say
| >
| > instance
| > #if blah
| >  {-# OVERLAPPABLE #-}
| > #endif
| >  Show a => Show [a] where ...
| >
| > Simon
| >
| > | -----Original Message-----
| > | From: Johan Tibell [mailto:[hidden email]]
| > | Sent: 29 July 2014 11:02
| > | To: Herbert Valerio Riedel
| > | Cc: Niklas Hambüchen; Haskell Libraries ([hidden email]);
| GHC
| > | users; Simon Peyton Jones; ghc-devs
| > | Subject: Re: Overlapping and incoherent instances
| > |
| > | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel
| > | <[hidden email]>
| > | wrote:
| > | > On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
| > | >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where .
| > | >>
| > | >> Is the syntax somewhat flexible in where the pragma can be
| placed?
| > | >> For example, some might prefer
| > | >>
| > | >>   {-# OVERLAPPING #-}
| > | >>   instance Show [Char] where .
| > | >
| > | > This variant may also be more convenient in cases where you need
| > | > to CPP-guard that pragma, as it's on a separate line.
| > |
| > | Agreed, and if we remove the old pragma (even with a deprecation
| > | cycle) you'll see quite a few of those as many library authors try
| > | to have their libraries compile with the last 3 major GHC versions.
| > |
| > | P.S. For e.g. INLINABLE we require that you mention the function
| > | name next to the pragma (which means that you can e.g. put the
| > | pragma after the declaration). What's the rationale to not require
| > |
| > | {-# OVERLAPPING Show [Char] #-}
| > |
| > | here? Perhaps it's too annoying to have to repeat the types?
| > _______________________________________________
| > Glasgow-haskell-users mailing list
| > [hidden email]
| > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| >

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

David Feuer
In reply to this post by Simon Peyton Jones
CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long, perhaps.

On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones
<[hidden email]> wrote:

> CAN_OVERLAP and CAN_BE_OVERLAPPED?
>
>
>
> (instead of OVERLAPPING and OVERLAPPABLE)
>
>
>
> Or CAN-OVERLAP, CAN-BE-OVERLAPPED
>
>
>
> That’s ok with me if that’s what you all want!
>
>
>
> Simon
>
>
>
> From: Glasgow-haskell-users
> [mailto:[hidden email]] On Behalf Of Krzysztof
> Skrzetnicki
> Sent: 29 July 2014 16:56
> To: Brandon Allbery
> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries
> ([hidden email]); ghc-devs
>
>
> Subject: Re: Overlapping and incoherent instances
>
>
>
> How about CAN_OVERLAP?
>
> --
> Krzysztof
>
> 29-07-2014 15:40, "Brandon Allbery" <[hidden email]> napisał(a):
>
> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <[hidden email]>
> wrote:
>
> +1. I like Niklas' syntax better.  Also OVERLAPPABLE is a horrible word,
> OVERLAPPING sound less formidable (even though it might be slightly less
> accurrate).
>
>
>
> We already get "overlap ok" in instance-related type errors, so OVERLAP_OK
> wouldn't be particularly alien even if it doesn't quite fit in with existing
> pragmas.
>
>
>
> --
>
> brandon s allbery kf8nh                               sine nomine associates
>
> [hidden email]                                  [hidden email]
>
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

David Thomas
Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear.

On Tue, Jul 29, 2014 at 9:52 AM, David Feuer <[hidden email]> wrote:

> CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long, perhaps.
>
> On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones
> <[hidden email]> wrote:
>> CAN_OVERLAP and CAN_BE_OVERLAPPED?
>>
>>
>>
>> (instead of OVERLAPPING and OVERLAPPABLE)
>>
>>
>>
>> Or CAN-OVERLAP, CAN-BE-OVERLAPPED
>>
>>
>>
>> That’s ok with me if that’s what you all want!
>>
>>
>>
>> Simon
>>
>>
>>
>> From: Glasgow-haskell-users
>> [mailto:[hidden email]] On Behalf Of Krzysztof
>> Skrzetnicki
>> Sent: 29 July 2014 16:56
>> To: Brandon Allbery
>> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries
>> ([hidden email]); ghc-devs
>>
>>
>> Subject: Re: Overlapping and incoherent instances
>>
>>
>>
>> How about CAN_OVERLAP?
>>
>> --
>> Krzysztof
>>
>> 29-07-2014 15:40, "Brandon Allbery" <[hidden email]> napisał(a):
>>
>> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <[hidden email]>
>> wrote:
>>
>> +1. I like Niklas' syntax better.  Also OVERLAPPABLE is a horrible word,
>> OVERLAPPING sound less formidable (even though it might be slightly less
>> accurrate).
>>
>>
>>
>> We already get "overlap ok" in instance-related type errors, so OVERLAP_OK
>> wouldn't be particularly alien even if it doesn't quite fit in with existing
>> pragmas.
>>
>>
>>
>> --
>>
>> brandon s allbery kf8nh                               sine nomine associates
>>
>> [hidden email]                                  [hidden email]
>>
>> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Iavor Diatchki
Hello,

I have no strong feelings about what words we use, but I wanted to point out that while we are thinking of names, we may want to consider 3 (and not just 2).  Currently we have:
  * OVERLAPPING:   This instances may overlap existing instances
  * OVERLAPPABLE: This instance may be overlapped by existing instances
  * OVERLAPS:  This instance is both OVERLAPPING and OVERLAPPABLE

Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated list of the first two, but I could not see how to make this work easily with GHC's pragmas.  It would not be hard to simply allow 2 pragmas after the `instance` keyword, but both of those seem rather long.

Either way, I'll keep an eye on the discussion, and would be happy to change the names if a consesus is reached.

-Iavor













On Tue, Jul 29, 2014 at 9:57 AM, David Thomas <[hidden email]> wrote:
Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear.

On Tue, Jul 29, 2014 at 9:52 AM, David Feuer <[hidden email]> wrote:
> CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long, perhaps.
>
> On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones
> <[hidden email]> wrote:
>> CAN_OVERLAP and CAN_BE_OVERLAPPED?
>>
>>
>>
>> (instead of OVERLAPPING and OVERLAPPABLE)
>>
>>
>>
>> Or CAN-OVERLAP, CAN-BE-OVERLAPPED
>>
>>
>>
>> That’s ok with me if that’s what you all want!
>>
>>
>>
>> Simon
>>
>>
>>
>> From: Glasgow-haskell-users
>> [mailto:[hidden email]] On Behalf Of Krzysztof
>> Skrzetnicki
>> Sent: 29 July 2014 16:56
>> To: Brandon Allbery
>> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries
>> ([hidden email]); ghc-devs
>>
>>
>> Subject: Re: Overlapping and incoherent instances
>>
>>
>>
>> How about CAN_OVERLAP?
>>
>> --
>> Krzysztof
>>
>> 29-07-2014 15:40, "Brandon Allbery" <[hidden email]> napisał(a):
>>
>> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <[hidden email]>
>> wrote:
>>
>> +1. I like Niklas' syntax better.  Also OVERLAPPABLE is a horrible word,
>> OVERLAPPING sound less formidable (even though it might be slightly less
>> accurrate).
>>
>>
>>
>> We already get "overlap ok" in instance-related type errors, so OVERLAP_OK
>> wouldn't be particularly alien even if it doesn't quite fit in with existing
>> pragmas.
>>
>>
>>
>> --
>>
>> brandon s allbery kf8nh                               sine nomine associates
>>
>> [hidden email]                                  [hidden email]
>>
>> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Overlapping and incoherent instances

Niklas Haas
In reply to this post by Simon Peyton Jones
On Tue, 29 Jul 2014 16:29:45 +0000, Simon Peyton Jones <[hidden email]> wrote:
> CAN_OVERLAP and CAN_BE_OVERLAPPED?
>
> (instead of OVERLAPPING and OVERLAPPABLE)
>
> Or CAN-OVERLAP, CAN-BE-OVERLAPPED
>
> That’s ok with me if that’s what you all want!
>
> Simon

For my 2¢, I think OVERLAPPING and OVERLAPPABLE are just fine - I
immediately understood what each word meant, there's no ugly ‘_’ or ‘-’
to agonize about for eternity. I would be +1 on just keeping those names
as-is.

I'm neutral about whether or not I like OVERLAPS as a combination of
both, I don't think that communicates quite clearly what's going on -
but I do think it's important to have a way to not have to write both
lengthy pragmas out.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Niklas Hambüchen
In reply to this post by Iavor Diatchki
On 29/07/14 19:28, Iavor Diatchki wrote:
> I have no strong feelings about what words we use, but I wanted to point
> out that while we are thinking of names, we may want to consider 3 (and
> not just 2).  Currently we have:
>   * OVERLAPPING:   This instances may overlap existing instances
>   * OVERLAPPABLE: This instance may be overlapped by existing instances
>   * OVERLAPS:  This instance is both OVERLAPPING and OVERLAPPABLE

I don't have an opinion about the naming, but would like to mention that
"OVERLAP" and "OVERLAPPABLE" would be in line with "INLINE" and "INLINABLE".
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Felipe Lessa
In reply to this post by Simon Peyton Jones

On 29-07-2014 20:41, Stephen Paul Weber wrote:

>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where ...
>
>> instance {-# OVERLAPPING #-} Show [Char] where ...
>
> This, to me, is an admission that developers are not going to want to turn
> overlapping on globally in general, and so the current language extensions
> would not make sense to get adopted into the core language at any point.  
> I agree with this idea, and so would second the proposal mentioned at
> <http://www.reddit.com/r/haskell/comments/2c136i/xoverlappinginstances_and_xincoherentinstances_to/cjb4jmr>
> that a language extension that adds actual keywords to tag instances that
> should be allowed to overlap be added, instead of resorting to pragmas.  
> This seems like an approach that could be useful in general and one could
> imagine moving "past" an extension to the core language at some point,
> potentially.
OTOH, the pragma is mostly harmless for older GHC versions, while the
keyword approach needs a preprocessor.

--
Felipe.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Andreas Abel
In reply to this post by Iavor Diatchki
Iavor,

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?

Is this correct?

Is it important to distinguish between OVERLAPPING and OVERLAPPABLE?  Why?

-- Andreas

On 29.07.2014 19:28, Iavor Diatchki wrote:

> Hello,
>
> I have no strong feelings about what words we use, but I wanted to point
> out that while we are thinking of names, we may want to consider 3 (and
> not just 2).  Currently we have:
>    * OVERLAPPING:   This instances may overlap existing instances
>    * OVERLAPPABLE: This instance may be overlapped by existing instances
>    * OVERLAPS:  This instance is both OVERLAPPING and OVERLAPPABLE
>
> Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated
> list of the first two, but I could not see how to make this work easily
> with GHC's pragmas.  It would not be hard to simply allow 2 pragmas
> after the `instance` keyword, but both of those seem rather long.
>
> Either way, I'll keep an eye on the discussion, and would be happy to
> change the names if a consesus is reached.
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Jul 29, 2014 at 9:57 AM, David Thomas <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear.
>
>     On Tue, Jul 29, 2014 at 9:52 AM, David Feuer <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      > CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little
>     long, perhaps.
>      >
>      > On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones
>      > <[hidden email] <mailto:[hidden email]>> wrote:
>      >> CAN_OVERLAP and CAN_BE_OVERLAPPED?
>      >>
>      >>
>      >>
>      >> (instead of OVERLAPPING and OVERLAPPABLE)
>      >>
>      >>
>      >>
>      >> Or CAN-OVERLAP, CAN-BE-OVERLAPPED
>      >>
>      >>
>      >>
>      >> That’s ok with me if that’s what you all want!
>      >>
>      >>
>      >>
>      >> Simon
>      >>
>      >>
>      >>
>      >> From: Glasgow-haskell-users
>      >> [mailto:[hidden email]
>     <mailto:[hidden email]>] On Behalf Of
>     Krzysztof
>      >> Skrzetnicki
>      >> Sent: 29 July 2014 16:56
>      >> To: Brandon Allbery
>      >> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries
>      >> ([hidden email] <mailto:[hidden email]>); ghc-devs
>      >>
>      >>
>      >> Subject: Re: Overlapping and incoherent instances
>      >>
>      >>
>      >>
>      >> How about CAN_OVERLAP?
>      >>
>      >> --
>      >> Krzysztof
>      >>
>      >> 29-07-2014 15:40, "Brandon Allbery" <[hidden email]
>     <mailto:[hidden email]>> napisał(a):
>      >>
>      >> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel
>     <[hidden email] <mailto:[hidden email]>>
>      >> wrote:
>      >>
>      >> +1. I like Niklas' syntax better.  Also OVERLAPPABLE is a
>     horrible word,
>      >> OVERLAPPING sound less formidable (even though it might be
>     slightly less
>      >> accurrate).
>      >>
>      >>
>      >>
>      >> We already get "overlap ok" in instance-related type errors, so
>     OVERLAP_OK
>      >> wouldn't be particularly alien even if it doesn't quite fit in
>     with existing
>      >> pragmas.
>      >>
>      >>
>      >>
>      >> --
>      >>
>      >> brandon s allbery kf8nh                               sine
>     nomine associates
>      >>
>      >> [hidden email] <mailto:[hidden email]>
>     [hidden email] <mailto:[hidden email]>
>      >>
>      >> unix, openafs, kerberos, infrastructure, xmonad
>     http://sinenomine.net
>      >>
>      >>
>      >> _______________________________________________
>      >> Libraries mailing list
>      >> [hidden email] <mailto:[hidden email]>
>      >> http://www.haskell.org/mailman/listinfo/libraries
>      >>
>      >>
>      >> _______________________________________________
>      >> Libraries mailing list
>      >> [hidden email] <mailto:[hidden email]>
>      >> http://www.haskell.org/mailman/listinfo/libraries
>      >>
>      > _______________________________________________
>      > Libraries mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > http://www.haskell.org/mailman/listinfo/libraries
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


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

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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Ivan Lazar Miljenovic
On 30 July 2014 22:07, Andreas Abel <[hidden email]> wrote:

> Iavor,
>
> 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.

>
> Is this correct?
>
> Is it important to distinguish between OVERLAPPING and OVERLAPPABLE?  Why?
>
> -- Andreas
>
>
> On 29.07.2014 19:28, Iavor Diatchki wrote:
>>
>> Hello,
>>
>> I have no strong feelings about what words we use, but I wanted to point
>> out that while we are thinking of names, we may want to consider 3 (and
>> not just 2).  Currently we have:
>>    * OVERLAPPING:   This instances may overlap existing instances
>>    * OVERLAPPABLE: This instance may be overlapped by existing instances
>>    * OVERLAPS:  This instance is both OVERLAPPING and OVERLAPPABLE
>>
>> Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated
>> list of the first two, but I could not see how to make this work easily
>> with GHC's pragmas.  It would not be hard to simply allow 2 pragmas
>> after the `instance` keyword, but both of those seem rather long.
>>
>> Either way, I'll keep an eye on the discussion, and would be happy to
>> change the names if a consesus is reached.
>>
>> -Iavor
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 29, 2014 at 9:57 AM, David Thomas <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear.
>>
>>     On Tue, Jul 29, 2014 at 9:52 AM, David Feuer <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>      > CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little
>>     long, perhaps.
>>      >
>>      > On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones
>>      > <[hidden email] <mailto:[hidden email]>> wrote:
>>      >> CAN_OVERLAP and CAN_BE_OVERLAPPED?
>>      >>
>>      >>
>>      >>
>>      >> (instead of OVERLAPPING and OVERLAPPABLE)
>>      >>
>>      >>
>>      >>
>>      >> Or CAN-OVERLAP, CAN-BE-OVERLAPPED
>>      >>
>>      >>
>>      >>
>>      >> That’s ok with me if that’s what you all want!
>>      >>
>>      >>
>>      >>
>>      >> Simon
>>      >>
>>      >>
>>      >>
>>      >> From: Glasgow-haskell-users
>>      >> [mailto:[hidden email]
>>     <mailto:[hidden email]>] On Behalf Of
>>     Krzysztof
>>      >> Skrzetnicki
>>      >> Sent: 29 July 2014 16:56
>>      >> To: Brandon Allbery
>>      >> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries
>>      >> ([hidden email] <mailto:[hidden email]>); ghc-devs
>>
>>      >>
>>      >>
>>      >> Subject: Re: Overlapping and incoherent instances
>>      >>
>>      >>
>>      >>
>>      >> How about CAN_OVERLAP?
>>      >>
>>      >> --
>>      >> Krzysztof
>>      >>
>>      >> 29-07-2014 15:40, "Brandon Allbery" <[hidden email]
>>     <mailto:[hidden email]>> napisał(a):
>>
>>      >>
>>      >> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel
>>     <[hidden email] <mailto:[hidden email]>>
>>
>>      >> wrote:
>>      >>
>>      >> +1. I like Niklas' syntax better.  Also OVERLAPPABLE is a
>>     horrible word,
>>      >> OVERLAPPING sound less formidable (even though it might be
>>     slightly less
>>      >> accurrate).
>>      >>
>>      >>
>>      >>
>>      >> We already get "overlap ok" in instance-related type errors, so
>>     OVERLAP_OK
>>      >> wouldn't be particularly alien even if it doesn't quite fit in
>>     with existing
>>      >> pragmas.
>>      >>
>>      >>
>>      >>
>>      >> --
>>      >>
>>      >> brandon s allbery kf8nh                               sine
>>     nomine associates
>>      >>
>>      >> [hidden email] <mailto:[hidden email]>
>>     [hidden email] <mailto:[hidden email]>
>>
>>      >>
>>      >> unix, openafs, kerberos, infrastructure, xmonad
>>     http://sinenomine.net
>>      >>
>>      >>
>>      >> _______________________________________________
>>      >> Libraries mailing list
>>      >> [hidden email] <mailto:[hidden email]>
>>
>>      >> http://www.haskell.org/mailman/listinfo/libraries
>>      >>
>>      >>
>>      >> _______________________________________________
>>      >> Libraries mailing list
>>      >> [hidden email] <mailto:[hidden email]>
>>
>>      >> http://www.haskell.org/mailman/listinfo/libraries
>>      >>
>>      > _______________________________________________
>>      > Libraries mailing list
>>      > [hidden email] <mailto:[hidden email]>
>>
>>      > http://www.haskell.org/mailman/listinfo/libraries
>>     _______________________________________________
>>     Libraries mailing list
>>     [hidden email] <mailto:[hidden email]>
>>
>>     http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> [hidden email]
> http://www2.tcs.ifi.lmu.de/~abel/
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123