RE: overlapping instances in 7.10.1

2015-06-14 Thread Sergei Meshveliani
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 (...)= Ring  (ResidueE a)   (A)
 instance (..., Ring (ResidueE a)) = Field (ResidueE a)   (B)

 
 * Module PFact__

   * Imports Pgcd_, which imports ResEuc_
 
   * Contains code that needs
 
(Field (ResidueE (UPol (ResidueE Integer  -- (X)
 
   * To solve (X) we use instance (B) from ResEuc_
   * And hence we need to solve 
  (Ring (ResidueE (UPol (ResidueE Integer
 
 which we do using (A) but not (C)
  
 
 * Module RsePol_

   * Imports PFact__
   * Contains the specialised instance
 
   instance (...) = Ring (ResidueE (UPol a)) -- (C)
 
 which overlaps instance (A)

 
 * Module Main
   * Needs an instance for
 
Field (ResidueE (UPol (Residue Integer)))  -- (Y)
 
   * Although GHC *could* generate this by instance declarations,
 which it would do using (B) and then using (C),
  
 instead GHC cleverly sees that it has generated it before,
 in module PFact__, and so uses the one from PFact__. 
 And that is what gives rise to your error

 
 So the real problem is that in PFact__, we make an instance (X) that
 does not see the specialised instance (C).  
 It *cannot* see that instance because RsePol_ imports PFact__.


(is is called  Pfact__).
Yes, I intended this. And this is not a problem. This is because Pfact_
uses somewhat a smaller knowledge library than there may use further
modules which import Pfact_.  


 So whatever code uses (X) is not going to see the specialised
 instance.

Why?

ghc-7.8.3  treats overlapping instances differently.

My intention was (and is) as follows.

Compiling Main, the compiler sees the two solutions for  (Y):
the one imported from  Pfact__  -- which implementation (dictionary?) is
ready,
and another that can be generated using (C) from  RsePol_.
By the  meaning of what are overlapping instances,  the compiler must
resolve between these two. And this is resolved by the rule of checking
the substitutional instance between instances.
`Main' imports more knowledge about instances than Pfact_ does, so it is
supposed to use an additional knowledge.  

The fact that one of the overlapping instances is already generated must
not be a sufficient reason to set it in  Main.

This is why I think that  ghc-7.8.3  treats the OI notion in a more
natural way than ghc-7.10.1 does.
May be, ghc-7.10.1 has a better technical tool for this, but  ghc-7.8.3 
corresponds to a natural notion of OI.

Can GHC return to a natural OI notion?
Or am I missing something?



   I bet that this is not what you intend. This may be a latent bug in
 DoCon.

If I am not missing anything in my above discourse, then DoCon is all
right at this point.


 I solved the problem by combining PFact__ and RsePol_ into a single 
 module.  Then everything works fine.

I think that this approach will generally lead to great difficulties in
composing an application.

Please, consider my above explanation and tell me whether I am missing
something.

Regards,

--
Sergei



 What are the general lessons here?
 
GHC generally assumes that if it generates (C T) in one place,
 then it can use that anywhere in the program that (C T) is needed.
 That is, there is only one (C T) dictionary.
 
  
 ·   But suppose you have overlapping instance in different
 modules; say
 
 module A where instance C [a]
 
 module B where import A; instance C [Maybe a]
 
 If you use (C [Maybe Int]) in A, then of course we won’t see the
 instance in B.  So you’ll get a different dictionary than if you
 compute C [Maybe Int] in module B.
 
  
 
 In short, overlapping instances are OK, but it’s best to put them in
 the same module as the instances they overlap. 
 
  
 
 Could GHC behave as if all instances were calculated afresh in the
 module being compiled.  Yes, of course it could, but at the cost of
 losing the benefit of cross-module specialisation.  An overloaded
 function specialised at, say, [Int] in one module could not be re-used
 in another in case the instances changed.
 
  
 
 Simon
 
  

 | -Original Message-
 | From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf
 Of
 | Sergei Meshveliani
 | Sent: 23 May 2015 22:08
 | To: glasgow-haskell-users@haskell.org
 | Cc: glasgow-haskell-b...@haskell.org
 | Subject: overlapping instances in 7.10.1

 | 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

 |  ghc 

ANNOUNCE: GHC 7.10.2 Release Candidate 1

2015-06-14 Thread Austin Seipp
We are pleased to announce the first release candidate for GHC 7.10.2:

https://downloads.haskell.org/~ghc/7.10.2-rc1
https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/

This includes the source tarball and bindists for Windows, Mac OS X,
and Debian Linux. FreeBSD and Solaris binaries will follow soon. These
binaries and tarballs have an accompanying SHA256SUMS file signed by
my GPG key id (0x3B58D86F).

We plan to make the 7.10.2 final release at the end of this coming
week - so please test as much as possible; bugs are much cheaper if we
find them before the release!

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


ANNOUNCE: GHC 7.10.2 Release Candidate 1

2015-06-14 Thread Austin Seipp
We are pleased to announce the first release candidate for GHC 7.10.2:

https://downloads.haskell.org/~ghc/7.10.2-rc1
https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/

This includes the source tarball and bindists for Windows, Mac OS X,
and Debian Linux. FreeBSD and Solaris binaries will follow soon. These
binaries and tarballs have an accompanying SHA256SUMS file signed by
my GPG key id (0x3B58D86F).

We plan to make the 7.10.2 final release at the end of this coming
week - so please test as much as possible; bugs are much cheaper if we
find them before the release!

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1

2015-06-14 Thread Andrés Sicard-Ramírez
On 14 June 2015 at 19:16, Austin Seipp aus...@well-typed.com wrote:
 We are pleased to announce the first release candidate for GHC 7.10.2:

Since transformers is a GHC-include library, is there any particular
reason why GHC 7.10.2 RC1 didn't include the latest version of the
transformers library, i.e. transformers-0.4.3.0?

-- 
Andrés
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users