Hugs-Users

Download

hugs-users@haskell.org

August 2022

1 participants
2 discussions

Re: [Hugs-users] FunDeps: divergent improvement from overlapping instances
by Anthony Clayden 22 Aug '22

22 Aug '22

> I'm now working on the instance sequencing routines, to ignore those > divergent Dependent positions when deciding overlap ordering. Ok. Done. So this works: >* class TypeEq a b e | a b -> e *>* instance TypeEq a a TTrue *>* instance TypeEq a b TFalse* In case of multiple FunDeps for an instance, improvement must use all FunDeps for a given instance, but not go on to improve from a less specific instance -- if one of the FunDeps is Full. Note a Full FunDep needn't actually deliver any improvement (change of types) for this 'don't go on' to apply -- it's sufficient if some other improvement has already got the Wanted to match the instance. (In effect this is selecting the instance -- although Hugs doesn't 'officially' do so until a later step.) Getting the preference sequence of instances was tricky -- especially in case of multiple FunDeps: in comparing two instance heads, they might be apart going by some FunDeps, but overlapping going by others.

1 0

FunDeps: divergent improvement from overlapping instances
by Anthony Clayden 12 Aug '22

12 Aug '22

The HList project (~2004) had to abandon Hugs because (for example) they couldn't express a type-level type equality test. Hugs rejects any attempt 'Instances are not consistent with Functional Dependencies'. Here's the equivalent that works in GHC. > class TypeEq a b e | a b -> e > instance TypeEq a a TTrue > instance {#- OVERLAPPABLE -#} (e ~ TFalse) => TypeEq a b e Hugs rejects the equivalent of these instances because it can unify the instance heads' determining positions (as TypeEq a a e0) but the improvement diverges. Hugs always treats a wildcard e0 as apart from any specific type or from any other wildcard; whereas GHC treats them as unifiable, so accepts the instances. The instances (whole heads) are overlappable, so GHC's overlapping instances mechanism will improve e ~ TFalse only on condition it can't unify types a, b at some usage site. SPJ points out https://gitlab.haskell.org/ghc/ghc/-/wikis/Functional-dependencies-in-GHC/K… that using an instance head to improve under a FunDep is a separate step and proceeds first vs selecting an instance. So this form for the second instance won't work in GHC: > instance TypeEq a b TFalse (Also the instance heads are not overlapping.) In case of TypeEq a a e0, instance improvement will find both instances match and improve e0 ~ TTrue, e0 ~ TFalse, then reject as inconsistent, same as Hugs. But notice this FunDep is 'Full' -- that is, mentions all of the classes, parameters. ('Full' FunDep is introduced in the 2008 'via CHRs' paper.) If improvement can use a Full FunDep matching to an instance head, it has in effect selected that instance. This is really using the instance as a _candidate_ for improvement -- it might be the Dependent types are already improved as far as possible before looking at this instance. (That is, if we already have [W] TypeEq Int Int TTrue, looking to the instance heads won't improve further; but Hugs is not smart enough to shortcut that TTrue can't be improved.) Hugs' type routines at this step of compilation are very much focussed on improving types, not selecting instances. And in case of a class with multiple FunDeps, the routines should 'fire' all possible FunDeps for each instance. However it's only a small mod in routine instImprove to say: upon matching to a Full FunDep for an instance, stop looking at other instances for improvement. A precondition is that it scans instances in most-specific-first sequence -- which Hugs is already doing. So I can write these instances > class TypeEq a b e | a b -> e > instance TypeEq a a TTrue > instance TypeEq a b TFalse Without needing to clutter the instances by deferring improvement to constraints. (This also makes type inference error messages less cluttered.) I'm now working on the instance sequencing routines, to ignore those divergent Dependent positions when deciding overlap ordering. AntC

1 1