DoCon and GHC
Serge D. Mechveliani
mechvel at botik.ru
Thu Jan 3 15:08:54 CET 2013
This is copying to the list my reply to Simon:
On Thu, Jan 03, 2013 at 12:57:02PM +0000, Simon Peyton-Jones wrote:
> OK I have tested with today's GHC 7.6.2, which is very slightly later
> than the release candidate.
> When I add (EuclideanRing (UPol k)) to the signature for cubicExt, the
> whole of demotest compiles. So that works.
Also ghc $doconCpOpt --make Main
must end with "No errors detected",
and take not more than 4 sec on a 2 GHz machine
(for suppose that an overlap is resolved unluckily for the cost, so that
the time becomes, say 60 sec).
> Your misconception is here:
> | c) Pol3_ has
> | instance (LinSolvRing (Pol a), CommutativeRing a) =>
> | LinSolvRing (UPol (Pol a))
> | But this does not overlap with Field k => LinSolvRing (UPol k).
> | Because Pol a is never of a Field nor of EuclideanRing.
> When matching instances, GHC does not take account of the context of the
> instance. Say you have
I knew this, and have forgotten. Thank you.
> If you don't care which of the overlapping instances is picked, then
> you can use -XIncoherentInstances. But you have to set that flag at
> the *instance declaration* not at the *use* of the instance. In this
> case it would be the instance for LinSolvRing (UPol k)
Probably, this will work good in one place where this instance is used,
and work bad in another place.
In the papers on algorithmic algebra the authors often compute some
foo for a domain T, and consider various methods for this computation,
and often a method is defined by the choice of the instance derivation.
And the author writes: apply the method defined by this and this
instance construction, this costs, say, O(n^3) bit operations,
and so on (literally, the word `instance' is not written).
So, there is not a problem of specifying the overlap resolving in papers
and lectures, this is done easily.
But Haskell+Glasgow does not provide a sufficient language construct for
such a resolving.
It has the rule of a "substitutionally more special instance".
Probably, something appropriate can be added to this rule.
Anyway, I shall wait for ghc-7.6.2, and see.
More information about the Glasgow-haskell-users