Re: [ghc-steering-committee] #433: the Unsatisfiable constraint; recommendation: accept

I’m in favor of the proposal overall, but if we include the ‘Warning’ machinery, I’d like to see Richard’s suggestion about a (flag :: Symbol) parameter, so that users can enable and disable custom warnings. Also, I don’t understand why we need a separate ‘Unsatisfiable’ class when we could reuse ’TypeError’ instantiated at kind ‘Constraint’. Adam lists this option in the Alternatives, but I wish it had a more detailed explanation why this is not possible. Just think of the API we are going to end up with: * TypeError * Unsatisfiable * Warning How come ‘Warning’ is a constraint like ‘Unsatisfiable’ rather than like ’TypeError’? I agree that each piece here makes sense individually, but we should also consider a more holistic approach to API design. Reusing ’TypeError’ is certainly tempting. - Vlad

On 27 Oct 2021, at 12:01, Tom Harding wrote:

Hi all,

Firstly, apologies for the radio silence - I’ve apparently been having some undiscovered email trouble (perhaps even since joining the committee), and so I’m now going to be using my usual, and hopefully far more reliable, email address.

With that said, I’d like to recommend proposal #433 for acceptance. The proposal does a good job of outlining the difference between this and the current TypeError mechanism, and I think the case is well justified. Certainly, the ability to bypass fundep checks in error case “instances” immediately brought to mind a handful of places in my own libraries that could benefit from this check.

I think the thread already contains a lot of committee activity, but I welcome any further comments!

Thanks, Tom _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee