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
          ./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.

Thanks,

------
Sergei




More information about the Glasgow-haskell-users mailing list