TypeFamilies vs. FunctionalDependencies & type-level recursion

José Pedro Magalhães jpm at cs.uu.nl
Wed Jun 22 11:08:53 CEST 2011


Hi Oleg,

On Wed, Jun 22, 2011 at 09:36, <oleg at okmij.org> wrote:

>
>
> > the need to define a duplicate of the class (MonadState' in your
> > example) bloats the code significantly.
>
> I'm quite puzzled at the statement. Is there really significant
> bloat? Let us count.
>
> As the first example, let's take
>        class C a
> with N special instances, mutually non-overlapping instances, and one
> catch-all instance "instance C a". We have N+1 instances total.
>
> With the technique in the earlier message, we define an auxiliary
>        class C' a flag
> with N special and one catch-all instance, all non-overlapping. We
> then define one instance of the original class C, performing the
> dispatch. The additional cost: one class declaration and one
> instance. Is one extra class and one instance considered a bloat?
> The extra class is systematically derived from the original one
> (so, one could get TH to do the deriving).
>

My problem is exactly with this unnecessary repetition. If the extra class
can be systematically derived from the original code, then it shouldn't have
to be specified. All I'm saying is that if we would want to have such a
mechanism for replacing OverlappingInstances, then we should also come up
with a way (possibly even involving new syntax) to make it intuitive to use.

(We've done something similar for the new generics stuff, by introducing
DefaultSignatures.)


>
> > But I am still doubtful of the runtime performance of your code
>
> I believe discussing performance may be a bit premature;


Perhaps, but this was prompted by your suggestion of considering deprecating
OverlappingInstances. I have lots of code that relies on it, and I wouldn't
want it to start triggering warnings just yet :-)


Cheers,
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20110622/50076be5/attachment.htm>


More information about the Haskell-prime mailing list