<pre style="white-space:pre-wrap;background-color:rgb(255,255,255)"><div dir="auto"> Anthony> I am interested in how you got into such a pickle in the first place:
Anthony> Why set `AllowAmbiguousTypes`? Did you understand what that means?
----------------------^^^^^^^^^^^^^^^^^^^^
>I read
> </div><div dir="auto">> </div><a href="https://stackoverflow.com/questions/49684655/how-dangerous-is-allowambiguoustypes-when-used-with-typeapplications">https://stackoverflow.com/questions/49684655/how-dangerous-is-allowambiguoustypes-when-used-with-typeapplications</a><div dir="auto">>
>
> which seems to indicate that using it is "a perfectly reasonable thing"
</div><div dir="auto">Hmm, I don't think that's how you got into the pickle. That SO answer (and there are plenty on the subject) says the "combination" of `AllowAmbiguousTypes` + `TypeApplications` is reasonable.</div><div dir="auto"><br></div><div dir="auto">But your first post had `AllowAmbiguousTypes` without `TypeApplications`. That is not "a perfectly reasonable thing"; no SO answer says it is. If you had already looked at that SO answer, how did you not use `TypeApplications`? Let me suggest how you got into the pickle, because there is a repeated experience here which is poor for learners:</div><div dir="auto"><br></div><div dir="auto">You wrote the method signature for `toBool`. That's ambiguous. GHC gave you an error message suggesting `AllowAmbiguousTypes` might get the method signature to compile -- which it did.</div><div dir="auto"><br></div><div dir="auto">`AllowAmbiguousTypes` works at the declaration site, not the usage site. Which is why:</div><div dir="auto"><br></div><div dir="auto">* It doesn't make sense to switch it on everywhere -- as one of the SO comments suggests.</div><div dir="auto">* It does need you to take action at the usage site, but GHC's message doesn't tell you that.</div><div dir="auto">* So your first post showed more `ambiguous` rejections at the usage site.</div><div dir="auto">* What's more there was a red herring about non-injective type families.</div><div dir="auto">* And to fix it per Li-yao's suggestion needs a whole bunch more extensions,</div><div dir="auto">* including the deeply flawed `ScopedTypeVariables`,</div><div dir="auto">* when the simpler `PatternSignatures` would be more appropriate -- except that's now deprecated.</div><div dir="auto">* `AllowAMbiguousTypes` is module-wide: that means you get no validation of any of your method sigs;</div><div dir="auto"> although probably you mean only a few of the to be ambiguous.</div><div dir="auto">* Then any/every usage site for any method might turn out to be ambiguous.</div><div dir="auto"><br></div><div dir="auto">IMO GHC has got itself into a total mess in this bit of the language, and the error messages lead learners rapidly into deep water. I think `AllowAmbiguousTypes` might as well be spelled `AllhopeAbandonTypes`.</div><div dir="auto"><br></div><div dir="auto">Those other extensions might be the best approach for your full requirements, but might not.</div><div dir="auto"><br></div><div dir="auto">So as to other possible designs:</div><div dir="auto"><br></div><div dir="auto">* I didn't want to get into the FunDeps vs TypeFamilies war.</div><div dir="auto"><br></div><div dir="auto">* If method `toBool` is only going to be called on the result of `toSubAmbi`, I would go</div><div dir="auto"><br></div><div dir="auto">> toBool :: a -> Bool -- not ambiguous</div><div dir="auto">></div><div dir="auto">> instance Ambi blah where</div><div dir="auto">> type SubAmbi blah = ...</div><div dir="auto">> toSubAmbi x = ...</div><div dir="auto">> toBool x = case toSubAmbi x of { ... -> True; _ -> False }</div></pre><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)"><div dir="auto">Then in your `whatsWrong` function, call only `toBool`. So the instances are a little more verbose but the usage sites are more succinct and don't need all those extensions.</div></pre><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)"><div dir="auto">AntC</div></pre>