To my request on overlapping instances in 6.6 candidate
Simon Peyton-Jones
[..]
GHC 6.6's story is that an instance declaration can only be overlapped if you compile that module with -fallow-overlapping-instances. Since the list instance for Show was not compiled in this way, you can't overlap it.
You may think this is annoying -- but it does mean that you can look at an instance declaration and see whether it might be overlapped, just by look at the flags for that module.
But why to restrict the user, why one needs to detect which library
instance can be overlapped? Why not to allow all of them to overlap?
Here is an example of how I alayws was using overlaps with standard
instances.
------------------------------------------------
data Equation = ...
instance Show Equation where ...
instance Show [Equation]
where
showsPrec _ eqs =
| ------------------------------------------------
| data Equation = ...
| instance Show Equation where ...
|
| instance Show [Equation]
| where
| showsPrec _ eqs =
Simon Peyton-Jones wrote:
| ------------------------------------------------ | data Equation = ... | instance Show Equation where ... | | instance Show [Equation] | where | showsPrec _ eqs =
| ------------------------------------------------ | | This gives the user possibility to redefine a certain part of the | library instance. | Is not ghc-6.4.1 better at this point? Perhaps. That's what I'd like feedback about. What do others think? (Incidentally, 6.5 has been like this for about a year without complaints. Also I made the change because people wanted to be able to *use* overlapping instances (defined in a library) without having to give the -fallow-overlapping-instances flag.)
Simon
Could overlapping instances be broken into two flags, once with each of the desired semantics? -- Chris
"Simon Peyton-Jones"
| What are the disadvantages of compiling every library | with -fallow-overlapping-instances? It's not H98, so it has to be an option, enabled by a flag. Of course you are free to put the flag at the top of every module. Sergey's point is that the libraries are pre-compiled, so you can't add flags to them. The old model was that every instance is potentially overlappable; and you only need the flag when you *use* the instances. But people complained that the clients of their library should not need to know "import Foogle and use -fallow-overlapping-instances". Simon
On 9/5/06, Simon Peyton-Jones
The old model was that every instance is potentially overlappable; and you only need the flag when you *use* the instances. But people complained that the clients of their library should not need to know "import Foogle and use -fallow-overlapping-instances".
I think that any module that depends on this feature in any way should require the flag. Foogle might define some overlapping instances which are meant to be used only in its implementation--that is, users of Foogle aren't meant to make use those instance declarations. In that scenario, I could see a case for not requiring importing modules to specify the flag. But, I think that depends on a mechanism for controlling whether or not an instance declaration get exported in order to be useful. - Brian
On Mon, Sep 04, 2006 at 03:39:06PM +0100, Simon Peyton-Jones wrote:
| ------------------------------------------------ | data Equation = ... | instance Show Equation where ... | | instance Show [Equation] | where | showsPrec _ eqs =
| ------------------------------------------------ | | This gives the user possibility to redefine a certain part of the | library instance. | Is not ghc-6.4.1 better at this point?
Perhaps. That's what I'd like feedback about.
Let me exlain a bit more the reason.
show [1, 2, 3] = "[1,2,3]" -- all right, let it be.
Now, for the list eqs :: [Equation], the GHC instance prints it, for
example, as
-------------------
[[21] n+0 = 0 (Parents [[1],[2]]),[22] n+(s n) = s (n+m) (Parents [[33],
[44]]),[23] n*0 = 0 (Parents [[],[]])]
-------------------
And I would like it to be at least
--------------------
[[21] n+0 = 0 (Parents [[1],[2]]),
[22] n+(s n) = s (n+m) (Parents [[33],[44]]),
[23] n*0 = 0 (Parents [[],[]])
],
--------------------
which is easier to read. I decided that to overlap with the ghc instance
is the simplest and best solution.
I thank Ian Lynagh
(Incidentally, 6.5 has been like this for about a year without complaints.
I am sorry for this, I am slower than GHC. I have been with 6.4.1 last 1-2 years, and ignored the further version matters. Finally, a week ago decided to look into what is coming with 6.6.
Also I made the change because people wanted to be able to *use* overlapping instances (defined in a library) without having to give the -fallow-overlapping-instances flag.)
The difference for me is to have a little bit less-or-more comfort. DoCon-2.09 has ported from 6.4.1 to 6.6-candidate only by removing the `data' name from `dependencies', and it looks like working all right. In Dumatel-1.06, it reports the error of this library overlap for `Show'. For exampl, I can define the showsList method, as Ian suggests. Generally, I suspect that ghc-6.4.1 is better at this point of library overlaps, but I am not sure. Anyway, the GHC developers have now more of feedback, they know better and can decide. Thanks, ----------------- Serge Mechveliani mechvel@botik.ru
Simon Peyton-Jones schrieb:
| instance Show [Equation] | where | showsPrec _ eqs =
[...]
Perhaps. That's what I'd like feedback about. What do others think?
Overlapping Show instances are desirable for debugging purposes or quick and dirty code (not for "nicer" ways). Cheers Christian
On Mon, Sep 04, 2006 at 06:22:34PM +0400, Serge D. Mechveliani wrote:
Here is an example of how I alayws was using overlaps with standard instances.
------------------------------------------------ data Equation = ... instance Show Equation where ...
instance Show [Equation] where showsPrec _ eqs =
This doesn't addrses the general issue, but in this case you can say
data Equation = ...
instance Show Equation where
showsPrec _ eq = ...
showList eqs =
participants (7)
-
Brian Smith -
Chris Kuklewicz -
Christian Maeder -
Ian Lynagh -
Rene de Visser -
Serge D. Mechveliani -
Simon Peyton-Jones