Re: Overlapping and incoherent instances

[Stephen Paul Weber]

Somebody signing messages as Felipe Lessa wrote:

OTOH, the pragma is mostly harmless for older GHC versions, while the
keyword approach needs a preprocessor.


Only if *both* the old LANGUAGE pragma and the new pragma were employed, 
which will generate a deprecation warning for awhile and then eventually 
(likely) be rejected by newer GHCs, thus requiring a prepropcessor in either 
case.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Felipe Lessa]

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



signature.asc
Description: OpenPGP digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Stephen Paul Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

>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 

 
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.

- -- 
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJT2DFBAAoJENEcKRHOUZzemmIQAJEbSjPyx745UI6mkuhBVhKl
LQWJlpu0/kzBHaFJl/mWcghKxoBFWwU+pCTh/Pr2oj0rp/KGskBLlplIqB4btZTA
ov2MpPrsHm1M37MuGyMtiBhs57UJE+saKKuvcH3qzLZyBCHorE3lFcKAFbNupBrL
e/vgNblQ70KGmDRAKqbAQHm9anoGeZUJPgQ9ylVEH4nBYLDo0YSNo/zTeB7fK2yv
xBE+Ul3YGfhzf82cLJhYNQOpi5wJ3JEDBevKXcGRzr4Mhzn2Lke+26tu0tx6sOSN
snPX2REoeQD1AfXvuNKSxV7BL+CQeyAOOmm2Isj3vW/oO3gkqpfRjCFc+ZSPEjlG
XQ3S7L7cgNB34rd6sOFzTv83PXvsH0a0d5RqKUM2kN/qGEjSbAQ1FVyJEUcaEmzr
jBnVnWq+abCOSOBg4joGfTxjq0zufdjxkzScEJVDVZ4pIXoxej7HJBi8UfIvo3Jo
EDMGGsLSedt4tR2LzYf/5up7GPfuBsFQQzuIcdgMG8/zYca7zWPJgyunlXAPcbzr
RvM/gf63SCBuVaQjrtv2Zhzp3PucWOL94NEmLYONU3uuEmo6bq1VO42fOUcl7X/1
UyhFbtoV7s/7PVClxdD4Ag9PumtSfl/CSvN0BA8AzDwTuHWNOPdThAHFqfAtRsD0
GyNzVRNOGuze9SqkLc4T
=YeKu
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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 
wrote:

> Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear.
>
> On Tue, Jul 29, 2014 at 9:52 AM, David Feuer 
> 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
> >  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:glasgow-haskell-users-boun...@haskell.org] On Behalf Of
> Krzysztof
> >> Skrzetnicki
> >> Sent: 29 July 2014 16:56
> >> To: Brandon Allbery
> >> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries
> >> (librar...@haskell.org); ghc-devs
> >>
> >>
> >> Subject: Re: Overlapping and incoherent instances
> >>
> >>
> >>
> >> How about CAN_OVERLAP?
> >>
> >> --
> >> Krzysztof
> >>
> >> 29-07-2014 15:40, "Brandon Allbery"  napisał(a):
> >>
> >> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel 
> >> 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
> >>
> >> allber...@gmail.com
> ballb...@sinenomine.net
> >>
> >> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> >>
> >>
> >> ___
> >> Libraries mailing list
> >> librar...@haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
> >>
> >>
> >> ___
> >> Libraries mailing list
> >> librar...@haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
> >>
> > ___
> > Libraries mailing list
> > librar...@haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> ___
> Libraries mailing list
> librar...@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

| 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 
| 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:johan.tib...@gmail.com]
| > | Sent: 29 July 2014 11:02
| > | To: Herbert Valerio Riedel
| > | Cc: Niklas Hambüchen; Haskell Libraries (librar...@haskell.org);
| 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
| > | 
| > | 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
| > Glasgow-haskell-users@haskell.org
| > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| >

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

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:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Krzysztof Skrzetnicki
Sent: 29 July 2014 16:56
To: Brandon Allbery
Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries 
(librar...@haskell.org); ghc-devs
Subject: Re: Overlapping and incoherent instances


How about CAN_OVERLAP?

--
Krzysztof
29-07-2014 15:40, "Brandon Allbery" 
mailto:allber...@gmail.com>> napisał(a):
On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel 
mailto:andreas.a...@ifi.lmu.de>> 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
allber...@gmail.com 
 ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

___
Libraries mailing list
librar...@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Krzysztof Skrzętnicki]

How about CAN_OVERLAP?

--
Krzysztof
 29-07-2014 15:40, "Brandon Allbery"  napisał(a):

> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel 
> 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
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> ___
> Libraries mailing list
> librar...@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Brandon Allbery]

On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel 
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
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Richard Eisenberg]

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  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:johan.tib...@gmail.com]
> | Sent: 29 July 2014 11:02
> | To: Herbert Valerio Riedel
> | Cc: Niklas Hambüchen; Haskell Libraries (librar...@haskell.org); 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 
> | 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
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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:johan.tib...@gmail.com]
| Sent: 29 July 2014 11:02
| To: Herbert Valerio Riedel
| Cc: Niklas Hambüchen; Haskell Libraries (librar...@haskell.org); 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 
| 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
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Krzysztof Skrzętnicki]

I think it may also lead to cleaner code. I would rather write a single
section like this:

#if NEW_GHC
{-# bunch of OVERLAPPABLE declarations #-}
#endif

at the start of the file rather than have to insert a lot of CPP-guarded
pragmas later. But it may be seen as an editor/IDE issue and bikeshedding
on the whole.

--
Krzysztof


On Tue, Jul 29, 2014 at 12:48 PM, Johan Tibell 
wrote:

> On Tue, Jul 29, 2014 at 12:37 PM, Daniel Trstenjak
>  wrote:
> >
> > On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
> >> What's the rationale to not require
> >>
> >> {-# OVERLAPPING Show [Char] #-}
> >>
> >> here? Perhaps it's too annoying to have to repeat the types?
> >
> > This one might be written at the top of the file, so it would be easier
> > to overlook it, than having it directly at the instance declaration,
> > which seems to be one of the major points for OVERLAPPING and
> OVERLAPPABLE.
>
> The same could be said for e.g. INLINE. The extra flexibility is nice
> to have (e.g. because you can opt to put the pragma after the
> declaration, to de-emphasize it.)
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Johan Tibell]

On Tue, Jul 29, 2014 at 12:37 PM, Daniel Trstenjak
 wrote:
>
> On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
>> What's the rationale to not require
>>
>> {-# OVERLAPPING Show [Char] #-}
>>
>> here? Perhaps it's too annoying to have to repeat the types?
>
> This one might be written at the top of the file, so it would be easier
> to overlook it, than having it directly at the instance declaration,
> which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE.

The same could be said for e.g. INLINE. The extra flexibility is nice
to have (e.g. because you can opt to put the pragma after the
declaration, to de-emphasize it.)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Daniel Trstenjak]

On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
> What's the rationale to not require
> 
> {-# OVERLAPPING Show [Char] #-}
> 
> here? Perhaps it's too annoying to have to repeat the types?

This one might be written at the top of the file, so it would be easier
to overlook it, than having it directly at the instance declaration,
which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE.


Greetings,
Daniel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Johan Tibell]

On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel  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
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users