Multi-requirement instances issue???

[Toricon]

When I try to Show a tuple, I get this error:

..\AppData\Roaming\Racket\6.10\pkgs\hackett-lib\hackett\private\base.rkt:305:11: Show162: arity mismatch;
the expected number of arguments does not match the given number
expected: 1
given: 2
arguments...:
#
#

So I expect that there's an issue with an instance being dependent on multiple other type classes.
It's not just tuples, either. I tried with my own multi-dependency typeclass, and it failed, giving a similar error (different mostly in that the data type was stored in a different file, I think). Could just be an issue with Show, but I somehow doubt it.

hackett/hackett-lib/hackett/private/base.rkt

Line 305 in f472859

dict-expr)]

[lexi-lambda]

Please include a short, self-contained, correct example that reproduces the issue, and I’ll take a look at fixing it.

[Toricon]

Github comments don't seem to support .rkt files, so here's the code.

#lang hackett

(instance
 (forall [f a] (Applicative f) (Semigroup a) => (Semigroup (f a)))
 [++ (lambda [a b] {{++ <$> a} <*> b})])
 ; has two constraints: (Applicative f) and (Semigroup a)
 ; the type-checker approves, but evaluation fails

(instance
 (forall [f a] (Applicative f) (Monoid a) => (Monoid (f a)))
 [mempty (pure mempty)])
 ; for completeness
 ; (also fails)

(def just_testing {(just "test") ++ (just "ing")})
  ; typechecks, but gives error on evaluation

This should reproduce the issue upon evaluation of just_testing.

[lexi-lambda]

Those instances are both evil, for what it’s worth. :) They overlap with almost everything… but you probably know that already. Detection of overlapping instances is not implemented yet, so that particular program is related to #25. The more specific problem is still relevant, though.

[Toricon]

If you want a less evil example, try printing (tuple 3 4) or something like that. It gives the same error.

Also, those instances are MATHEMATICALLY PERFECT. The fact that they act terribly is just because no system has yet been created that is powerful enough to hold them.

(Seriously, though, there's an undeniable correspondence between applicative functors and monoids that is simply beautiful, and I think it should at least be recognized, even if perhaps it's not all that useful.)

[lexi-lambda]

Oh, they’re very useful! It would also be extremely nice for those instances to exist. The troubling thing is when there are two such beautiful instances with different constraints that overlap, and that makes instance resolution rather troubling…

[Toricon]

That is a major problem, but I think/hope there's a better solution than "forbid overlap". At http://www.haskellforall.com/2012/05/scrap-your-type-classes.html, there is an example for how to manually give functions instances, but it means you have to assign everything yourself, which usually isn't worth the headache. Haskell uses newtypes (so there are multiple types for multiple instances, to maintain the "only one" rule) but those aren't implemented yet, and they don't quite sit right with me when used like that.

...I honestly don't know the best way to solve this problem, or if there is one. If I find alternative solutions, I'll see how workable they are and update you.

(The descriptions for the solutions and their flaws are mostly me spelling things out explicitly, for my own sake ("completeness"), not me explaining something you already know.)

[lexi-lambda]

The GHC folks have done interesting work towards these things. There are various solutions, including (IIRC) closed type classes, instance chains, or “disequality” constraints. Those all make things more complicated, but there’s no inherent reason Hackett can’t support them. That’s a separate feature request, though (and not one I anticipate I will prioritize right now).