) example illustrating of how
overlapping instances (OI)
are used in DoCon.
Also this example is made after the sample that Simon has given in his
recent letter:
[..]
2) At least ghc-7.8.3 and ghc-7.10.1 do the same in this example.
May be, you can change this example a bit to make ghc
) on ghc-7.8.3.
But I need to understand the subject of overlapping instances (OI).
--
I am writing this _here_ because to clicking at
https://ghc.haskell.org/trac/ghc/ticket/10526
my browser responds Problem occurred while loading the URL
https://ghc.haskell.org/trac/ghc
be
resolved differently there.
Now, I give a simple (and a very contrived) example illustrating of how
overlapping instances (OI)
are used in DoCon.
Also this example is made after the sample that Simon has given in his
recent letter:
GHC generally assumes that if it generates
(the instance)
(C T
On Sat, 2015-06-13 at 23:07 +, Simon Peyton Jones wrote:
(I reformat this text a bit)
[..]
I finally found time to look into what is happening here. It’s a good
illustration of the dangers of overlapping instances. Here is the
setup:
* Module ResEuc_
* Contains
instance
Sergei
I finally found time to look into what is happening here. It's a good
illustration of the dangers of overlapping instances. Here is the setup:
* Module ResEuc_
* Contains
instance (...)= Ring (ResidueE a) (A)
instance (..., Ring
Dear GHC developers,
This request overrides my previous one of 7.10.1-err...
(it is simpler and more precise).
The archive
http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2015.zip
presents a question about ghc-7.10.1.
Make it, please, with ghc-7.10.1 by
-XOverlappingInstances).
Finally, it has come to this module:
-
Preprocessing library docon-2.12.1...
[48 of 86] Compiling ResRing__ ( ResRing__.hs, dist/build/ResRing__.o )
ResRing__.hs:183:31:
Overlapping instances for Eq (Maybe PropValue)
arising
-XOverlappingInstances).
Finally, it has come to this module:
-
Preprocessing library docon-2.12.1...
[48 of 86] Compiling ResRing__ ( ResRing__.hs, dist/build/ResRing__.o )
ResRing__.hs:183:31:
Overlapping instances for Eq (Maybe PropValue
Dear GHC developers,
Please, test ghc-7.10.1 on making docon-2.12
http://www.botik.ru/pub/local/Mechveliani/docon/
and running itsdemotest/Main
(see install.txt).
docon-2.12 has been tested under ghc-7.8.2,
and it has
extensions: ... OverlappingInstances
in
Now, I delete `OverlappingInstances' from docon.cabal
and also from the $doconCpOpt options to call ghc on
demotest/Main.hs.
And now the test runs correct in ghc-7.10.1 !
Only it is 1.5 times slower than in ghc-7.8.2.
So:
a) The test intends overlapping instances,
b) instance
it is 1.5 times slower than in ghc-7.8.2.
So:
a) The test intends overlapping instances,
b) instance overlaps are not declared for ghc-7.10.1,
c) this leads to a correct running, but 1.5 times slower.
I do not know of whether this slow down is due to the removed pragma or
due to other
#7171: erroneous overlapping instances reported with FunDeps
-+--
Reporter: jwlato | Owner:
Type: bug | Status: closed
#7171: erroneous overlapping instances reported with FunDeps
-+--
Reporter: jwlato | Owner:
Type: bug | Status: closed
#7171: erroneous overlapping instances reported with FunDeps
-+--
Reporter: jwlato | Owner:
Type: bug | Status: closed
#7171: erroneous overlapping instances reported with FunDeps
-+--
Reporter: jwlato | Owner:
Type: bug | Status: new
#7171: erroneous overlapping instances reported with FunDeps
-+--
Reporter: jwlato | Owner:
Type: bug | Status: new
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: closed
Priority: highest
#7171: erroneous overlapping instances reported with FunDeps
+---
Reporter: jwlato | Owner:
Type: bug | Status: new
#7171: erroneous overlapping instances reported with FunDeps
-+--
Reporter: jwlato | Owner:
Type: bug | Status: closed
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: closed
Priority: highest
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: closed
Priority: highest
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: closed
Priority: highest
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: closed
Priority: highest
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: closed
Priority: highest
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: closed
Priority: highest
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: merge
Priority: highest
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: merge
Priority: highest
#7171: erroneous overlapping instances reported with FunDeps
-+--
Reporter: jwlato | Owner:
Type: bug | Status: closed
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: highest | Milestone
#7150: unjustified overlapping instances error
+---
Reporter: maeder | Owner:
Type: bug| Status: closed
Priority: highest
#7171: erroneous overlapping instances reported with FunDeps
---+
Reporter: jwlato | Owner:
Type: bug| Status: new
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: normal| Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: normal| Milestone
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: normal| Milestone
#7150: unjustified overlapping instances error
---+
Reporter: maeder | Owner:
Type: bug| Status: new
Priority: normal
#7150: unjustified overlapping instances error
-+--
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: normal| Milestone
On Tue, Jun 5, 2012 at 2:25 PM, Gábor Lehel illiss...@gmail.com wrote:
The encoded version would be:
instance (f a b) = FMap f (HJust a) (HJust b)
where type f :$: (HJust a) = HJust b
and I think this actually demonstrates a *different* limitation, namely that
The RHS of an associated
On Tue, Jun 5, 2012 at 4:18 AM, Etienne Laurin etie...@atnnn.com wrote:
Thanks for the idea. Here it is.
http://hackage.haskell.org/trac/ghc/wiki/TFvsFD
I posted my comments on the matter along with many additional comments
and examples that I found.
Thanks!
One part is confusing me.
In
| My take is that we should abandon Fundeps, and concentrate on
| introducing overlaps into type functions in a controlled way (what
| I've called 'dis- overlapped overlaps'.)
|
| Abandoning fundeps would be a sad day for type-level programming.
| There are many things other than overlaps that
Simon Peyton-Jones simonpj at microsoft.com writes:
| My take is that we should abandon Fundeps, and concentrate on
| introducing overlaps into type functions in a controlled way (what
| I've called 'dis- overlapped overlaps'.)
|
| Abandoning fundeps would be a sad day for type-level
| Abandoning fundeps would be a sad day for type-level programming.
| There are many things other than overlaps that you can do with fundeps
| and constraint kinds that you cannot currently do with type families,
| such as:
|
| - Partial application or higher-order programming.
| -
Hello,
There is no problem if an instances uses a type family in it's
assumption---the instances should be accepted only if GHC can see enough of
the definition of the type family to ensure that the functional dependency
holds. This is exactly the same as what it would do to check that a super
Hello,
2012/6/1 Iavor Diatchki iavor.diatc...@gmail.com:
There is no problem if an instances uses a type family in it's
assumption---the instances should be accepted only if GHC can see enough of
the definition of the type family to ensure that the functional dependency
holds. This is
2012/5/31 Iavor Diatchki iavor.diatc...@gmail.com:
Hello,
the notion of a functional dependency is well established, and it was used
well before it was introduced to Haskell (for example, take a look
at http://en.wikipedia.org/wiki/Functional_dependency). So I'd be weary to
redefine it
Iavor Diatchki iavor.diatchki at gmail.com writes:
Hello,
the notion of a functional dependency is well established, and it was used
well before it was introduced to Haskell (for example, take a look
at http://en.wikipedia.org/wiki/Functional_dependency). So I'd be weary to
redefine it
if it was unsound for
fundeps too. (I don’t think anyone has done a soundness proof for fundeps
+ local constraints + overlapping instances, have they?) And indeed I
think it is.
It would be unsound only if the functional dependencies are not checked
properly (which, as you say, is similar
Hello,
I disagree with your example.
1. Check that an instance is consistent with itself. For example, this
should be rejected:
instance C a b
because it allows C Int Bool and C Int Char which violate the functional
dependency.
Functional dependencies are not used to pick types, they
Hello,
the notion of a functional dependency is well established, and it was used
well before it was introduced to Haskell (for example, take a look at
http://en.wikipedia.org/wiki/Functional_dependency). So I'd be weary to
redefine it lightly.
Note that placing a functional dependency
constraint.)
Does the overall instance chain structure guarantee termination of type
inference? I don't follow the algebra enough to be sure.
Morris Jones' examples seem to me contrived: they've set up overlapping
instances where you could avoid them, and even where they seem harder to
follow. Yes
Gábor Lehel illissius at gmail.com writes:
On Fri, May 25, 2012 at 7:06 AM, AntC anthony_clayden at clear.net.nz
wrote:
But it looks like the work SPJ pointed to is using closed style. ...
If you're referring to the NewAxioms work Simon linked to in the other
thread, I don't see it
On Fri, May 25, 2012 at 7:06 AM, AntC anthony_clay...@clear.net.nz wrote:
But it looks like the work SPJ pointed to is using closed style. If all
they're trying to do is support HList and similar, I guess that's good enough.
I tried to explain all this the best part of a year ago. (Admittedly
Simon Peyton-Jones simonpj at microsoft.com writes:
[from 7 Jul 2010. I've woken up this thread at Oleg's instigation
http://www.haskell.org/pipermail/haskell-prime/2011-July/003491.html ]
I'm not going to talk about Fundeps. This is about introducing overlapping
instances into type
overlapping
instances into type families. But I mean dis-overlapped overlaps, with dis-
equality guards on the instances:
http://www.haskell.org/pipermail/haskell-prime/2012-May/003689.html
This is essentially the same proposal as the July 2011 discussion, but a
little updated with actual experience of type
Twan van Laarhoven twanvl at gmail.com writes:
On 24/05/12 14:14, AntC wrote:
Simon Peyton-Jonessimonpjat microsoft.com writes:
Have you considered the alternative notation where multiple guards are
allowed,
as in normal function definitions? Something like:
type instance F
I think it is one case where you should use newtype instead of type, so that
it is not just a simple type synonym, but an actual other type.
With type, you're just making an alias, but Haskell sees the same type. A
newtype wrapper will hide this, at the price of having to define a (unique)
I agree, but with a slight difference. Since I am so lazy, if Binary
fits, like 80% of my requirements, for example this case, only
[String] is not OK. I'd like to reuse it with a little modification
made by myself, rather than re-write almost the whole of it.
But for Data.Binary, I think this
Magicloud Magiclouds schrieb:
Hi,
I am using Data.Binary which defined instance Binary a = Binary
[a]. Now I need to define instance Binary [String] to make
something special for string list.
How to make it work? I looked into the chapter of
overlappinginstances, nothing works.
Hello,
I only use the 'Binary' class when I don't care about the specifics of
the serialization format, only that it be reasonably fast, compact and
stable.
When I need to comply with some particular format I use the functions
in Data.Binary.Builder and Data.Binary.Get directly. Sometimes I make
Hi,
I am using Data.Binary which defined instance Binary a = Binary
[a]. Now I need to define instance Binary [String] to make
something special for string list.
How to make it work? I looked into the chapter of
overlappinginstances, nothing works.
--
竹密岂妨流水过
山高哪阻野云飞
Am 05.01.2011 09:24, schrieb Magicloud Magiclouds:
Hi,
I am using Data.Binary which defined instance Binary a = Binary
[a]. Now I need to define instance Binary [String] to make
something special for string list.
How to make it work? I looked into the chapter of
overlappinginstances,
Hello,
{-# LANGUAGE OverlappingInstances, FlexibleInstances #-}
import Data.Binary
instance Binary [String] where
get = undefined
put = undefined
works fine here on GHC 6.12.3. That being said, it would be safer
perhaps to add a newtype around [String] so you can
You can't. If you have special semantics for [String], then it is not
really a [String], it is something else. So let the type system know
that:
newtype SomethingElse = SomethingElse [String]
instance Binary SomethingElse where
...
On Wed, Jan 5, 2011 at 1:24 AM, Magicloud Magiclouds
You have two choices (other people have enumerated the first while I
was typing):
First choice:
Wrap your Stringlist with a newtype:
newtype StringList = StringList [String]
The downside of this your code gets polluted with the newtype.
Second choice:
Write special putStringList and
Steffen Schuldenzucker:
Sure. GHC would prompt that.
Jasper Van der Jeugt:
Not working with ghc7. But there sure are some threads about this
kind of things. I do not know if this is a bug of 6.* or 7, either.
Luke Palmer:
Sorry, by special, I meant, for example, [a, b] will be ab by
#4259: Add overlapping instances for type families
+---
Reporter: lilac|Owner:
Type: feature request | Status: new
Priority: normal
/6.12.1/html/users_guide/type-
families.html user's guide] says:
The instance declarations of a type family used in a single program may
only overlap if the right-hand sides of the overlapping instances coincide
for the overlapping types. More formally, two instance declarations
overlap
Oleg points out, and Martin also mentions, that functional dependencies appear
to interact OK with overlapping instances, but type families do not. I this
impression is mistaken, and I'll try to explain why in this message, in the
hope of exposing any flaws in my reasoning.
We can't permit
This is a tricky one. The motivating example is this:
-- Overlapping instances
instance Show a = Show [a] where ...
instance Show Char where ...
data T where
MkT :: Show a = [a] - T
f :: T - String
f (MkT xs) = show xs ++ \n
Here it's clear that the only way to discharge
to make use of the
general
versions of overlapping instances if any fit.
I don't think it's the same thing. The whole point of the existential
is that at the creation site of any value of type Ex the type of the
value being packaged is hidden. At the use site, therefore, the only
suitable
On Wednesday 03 February 2010 11:34:27 am Stefan Holdermans wrote:
I don't think it's the same thing. The whole point of the existential
is that at the creation site of any value of type Ex the type of the
value being packaged is hidden. At the use site, therefore, the only
suitable instance
to make use of the general
versions of overlapping instances if any fit.
So, I never really regarded this as anything more than an oddity that's
unlikely to come up. And it might be working as intended. But I thought
perhaps I should ask: is this intended? One could probably build a case that
baz
#565: overlapping instances fundeps broken
--+-
Reporter: ashley-y | Owner: simonpj
Type: bug | Status: closed
Priority: low
#565: overlapping instances fundeps broken
--+-
Reporter: ashley-y | Owner:
Type: bug | Status: new
Priority: low
#565: overlapping instances fundeps broken
--+-
Reporter: ashley-y | Owner: simonpj
Type: bug | Status: new
Priority: low
#565: overlapping instances fundeps broken
+---
Reporter: ashley-y |Owner:
Type: bug | Status: new
Priority: low
(version a) ++ , ++
users = % ++ show users ++ }
When I run it however, I get this:
*Main te - createEngine Hello 1 2
*Main s - tshow te
interactive:1:5:
Overlapping instances for TShow Engine
arising from a use of `tshow' at interactive:1:5-12
Matching instances
On Mon, Dec 8, 2008 at 4:43 AM, Tobias Bexelius
[EMAIL PROTECTED] wrote:
{-# LANGUAGE OverlappingInstances #-}
With this extension, the most specific instance will be used, i.e.
instance TShow Engine for Engine's, no matter if it is an instance of
Show.
Of course, down this way madness lies
Hi,
This is neat - but not quite what I was hoping for. My intended use
was to build a number of packages and produce a listing of all
overlapping instances, without knowing in advance which classes might
contain overlap. This is why I was hoping to instrument GHC instead
of using the existing
Hello,
I'm currently studying the use of overlapping instances, and I was
hoping to instrument GHC to produce some variety of list of instances
that overlapped. I haven't done any GHC hacking so far, so I'm not
entirely familiar with the code base. Does anyone have any guidance
on which modules
I'm currently studying the use of overlapping instances, and I was
hoping to instrument GHC to produce some variety of list of instances
that overlapped. I haven't done any GHC hacking so far, so I'm not
entirely familiar with the code base. Does anyone have any guidance
on which modules I
= a
module Main where
import A
import B
import C
main = do putStrLn $ a0= ++ show a0
putStrLn $ a1= ++ show a1
This works, because of the way the instances are used. While overlapping
instances are imported into Main, they are not used in Main.
Then that is a GHC bug
Sean Leather wrote:
That's interesting. So, maybe there should be some language extension or
warning (with associated -fno-warn) for this in GHC.
Personally, I prefer the way it's done now. (I guess that's obvious,
considering I'm developing a library that will take advantage of it. ;) )
But it
On Mon, Jun 09, 2008 at 09:21:02AM +0100, Simon Peyton-Jones wrote:
This isn't great, but it's not really different than is the case for
non-overlapping instances. Suppose module B1 declares 'instance C T',
and uses that instance; and module B2 declares a *different* 'instance
C T
Yes indeed, this is one of those well-known (ie not at all well
known, but folk lore) problems with overlapping instances, at least in
programs where different instances can be in scope at different times.
I think these examples are subtly different (eg, some trip up Hugs as
well, some only GHC
Yes indeed, this is one of those well-known (ie not at all well known, but
folk lore) problems with overlapping instances, at least in programs where
different instances can be in scope at different times.
It's discussed (not very clearly) in
http://www.haskell.org/ghc/docs/latest/html
This isn't great, but it's not really different than is the case for
non-overlapping instances. Suppose module B1 declares 'instance C T',
and uses that instance; and module B2 declares a *different* 'instance
C T', and uses that instance; and Main imports B1 and B2, but does not
use either
Hello,
(you should be able to copy and paste the code in this email into two
modules called A and B to try it out)
{-# LANGUAGE OverlappingInstances #-}
module A where
This module, together with module 'B', illustrates a problem in some
implementations of overlapping instances
Hello,
Isaac, this works for me.
Thx a lot,
Steffen
2007/12/5, Isaac Dupree [EMAIL PROTECTED]:
Steffen Mazanek wrote:
Hi,
Stefan and Isaac, thx for providing quick advice.
@Stefan: Unfortunately I have to use a list.
@Isaac: I do not get it. Could you please provide a short
is enough. I have
tried -XOverlappingInstances, -XFlexibleInstances and also
-XIncoherentInstances, however I still got an overlapping
instances error for this declaration.
You shouldn't use lists if you need to have special instance behavior -
lists are for perfectly ordinary sequences of things
Steffen Mazanek wrote:
Hi,
Stefan and Isaac, thx for providing quick advice.
@Stefan: Unfortunately I have to use a list.
@Isaac: I do not get it. Could you please provide a short example of your
approach?
The question still remains. Which arguments do I have ghc to start with to
get the same
1 - 100 of 254 matches
Mail list logo
