| 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?
Well it all depends what you mean by "natural". To me it is profoundly
un-natural to deliberately have the same type-class constraint solved in two
different ways in the same program!
To require this would prevent cross-module specialisation. If I have
f :: C a => a -> a
in one module, and I specialise it to
f_spec :: [Int] -> [Int]
in one module, I want to be free to re-use that specialisation in other
modules. But under your "natural" story, I cannot do that, because (C [Int])
might be resolved differently there.
I'd be interested in what others think. I've started
https://ghc.haskell.org/trac/ghc/ticket/10526
to collect these points.
Meanwhile, Sergei, it's clear how to fix docon, so you are no longer stuck.
Simon
|
|
|
| > 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 $doconCpOpt -O --make Main
| > | ,
| > | $doconCpOpt =
|
| > | -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports
| > | -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns
| > | -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances
| > | -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30
| >
| > |
| > | as it is written there in README.txt.
| > | README.txt explains which two instances are wrongly resolved
| > | -- as I expect.
|
| > | In ghc-7.8.2 they are resolved in a correct way
| > | (and there is a different pragma syntax).
| > | I conclude this from running the test in docon-2.12.
|
| > | Am I missing something?
| > | Please, advise,
|
| > | ------
| > | Sergei
|
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
