Re: Hugging to bits (cont)
Anthony Clayden <[email protected]> Fri, 28 Sep 2018 23:20:27 +1200
| Newsgroups | gmane.comp.lang.haskell.hugs.user |
|---|---|
| Message-ID | <CAM7nRYTtrcmxCdpi+tPk_5rMkJX46aofUPANst37AEfu_NDUeg@mail.gmail.com> |
--===============7996805059168636910== Content-Type: multipart/alternative; boundary="0000000000002b4b7f0576eca54d" --0000000000002b4b7f0576eca54d Content-Type: text/plain; charset="UTF-8" On Sat, 28 Jul 2018 at 12:35 PM, Anthony Clayden < [email protected]> wrote: > ... > So I have a modified version of the FD consistency rules, that supports > expressing a type-level type equality test, but avoids the bogusness in GHC > Trac #10675. With the equality test I can now express all the examples in > the HList paper [2004] -- those guys abandoned Hugs. > > I have a better version of the instance overlap rules, determined > statically from examining instance heads. IMO GHC's deferred checking is > far too shonky: you think your instances are OK then many moons later you > (or more likely somebody using your library) gets puzzling rejections to do > with overlaps. > Specifically, I've implemented the suggestion here https://ghc.haskell.org/trac/ghc/ticket/15632#comment:2 (Suggested/implemented after experimenting with some exotic variations; also after ditching the FunDep consistency rule altogether, as an experiment -- which behaved sensibly if you kept your instances sensible, but triggered some truly weird stuff too.) It seems to be going OK with 'ordinary code'. But overlapping TRex instances with FunDeps are giving indigestion. The trouble seems to be that internally TRex uses polykinds (row variables are Kind row, not `*`; labels seem to be something else again). I'm not sure whether type improvement through FunDeps is able to poke inside row Kinds. > A quick q in case anybody's listening: Hugs used to have something called > 'Multi-instance' overlap resolution. There's references to it in the code > and older documentation. But it's broken and was withdrawn. Anybody know > what it was trying to do or where I can find docos? It seems it was trying > to defer checking much like GHC, in which case I won't pursue it. > Some detail in an old version of the Higs manual, section 7.1.3 Overlapping instances, option +m https://www.haskell.org/hugs/pages/hugsman/exts.html#sect7.1.3 "a lazier form of overlapping instances", but no it's not GHC's deferred checking: it's looking at constraints to see if it can disambiguate instance selection by finding an instance for which constraints hold/reject instances whose head matches the wanted but whose constraints don't hold. There's an example. Wow! sounds hairy, although that behaviour is what newbies always think they're getting with constraints. Makes instance selection undecidable, in general. I'm not surprised it's broken, and I'm certainly not going to wade into that swamp. Note Hugs works hard at instance-processing/validation time (i.e. before it considers wanteds) to join up instances to constraints to instances of the constraint class. It builds a data structure around each instance decl, so the info is at its fingertips for doing "multi-instance resolution". AntC --0000000000002b4b7f0576eca54d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div><br></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat,= 28 Jul 2018 at 12:35 PM, Anthony Clayden <<a href=3D"mailto:anthony_cla= [email protected]">[email protected]</a>> wrote:<br></div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"><div dir=3D"auto">...</div><div dir=3D"auto">So= I have a modified version of the FD consistency rules, that supports expre= ssing a type-level type equality test, but avoids the bogusness in GHC Trac= #10675. With the equality test I can now express all the examples in the H= List paper [2004] -- those guys abandoned Hugs.</div><div dir=3D"auto"><br>= </div><div dir=3D"auto">I have a better version of the instance overlap rul= es, determined statically from examining instance heads. IMO GHC's defe= rred checking is far too shonky: you think your instances are OK then many = moons later you (or more likely somebody using your library) gets puzzling = rejections to do with overlaps.</div><div dir=3D"auto"></div></blockquote><= div dir=3D"auto"><br></div><div dir=3D"auto">Specifically, I've impleme= nted the suggestion here=C2=A0<div><a href=3D"https://ghc.haskell.org/trac/= ghc/ticket/15632#comment:2">https://ghc.haskell.org/trac/ghc/ticket/15632#c= omment:2</a></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">(Sugg= ested/implemented after experimenting with some exotic variations; also aft= er ditching the FunDep consistency rule altogether, as an experiment -- whi= ch behaved sensibly if you kept your instances sensible, but triggered some= truly weird stuff too.)</div><div dir=3D"auto"><br></div><div dir=3D"auto"= >It seems to be going OK with 'ordinary code'. But overlapping TRex= instances with FunDeps are giving indigestion. The trouble seems to be tha= t internally TRex uses polykinds (row variables are Kind row, not `*`; labe= ls seem to be something else again). I'm not sure whether type improvem= ent through FunDeps is able to poke inside row Kinds.</div><div dir=3D"auto= "><br></div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div= dir=3D"auto"><br></div><div dir=3D"auto">A quick q in case anybody's l= istening: Hugs used to have something called 'Multi-instance' overl= ap resolution. There's references to it in the code and older documenta= tion. But it's broken and was withdrawn. Anybody know what it was tryin= g to do or where I can find docos? It seems it was trying to defer checking= much like GHC, in which case I won't pursue it.</div></blockquote><div= dir=3D"auto"><br></div><div dir=3D"auto">Some detail in an old version of = the Higs manual, section 7.1.3 Overlapping instances, option +m=C2=A0<div><= a href=3D"https://www.haskell.org/hugs/pages/hugsman/exts.html#sect7.1.3">h= ttps://www.haskell.org/hugs/pages/hugsman/exts.html#sect7.1.3</a></div><div= dir=3D"auto"><br></div><div dir=3D"auto">"<span style=3D"font-family:= -webkit-standard;font-size:medium;background-color:rgb(255,255,255)">a lazi= er form of overlapping instances", but no it's not GHC's defer= red checking: it's looking at constraints to see if it can disambiguate= instance selection by finding an instance for which constraints hold/rejec= t instances whose head matches the wanted but whose constraints don't h= old. There's an example. Wow! sounds hairy, although that behaviour is = what newbies always think they're getting with constraints. Makes insta= nce selection undecidable, in general. I'm not surprised it's broke= n, and I'm certainly not going to wade into that swamp.</span></div></d= iv><div dir=3D"auto"><br></div><div dir=3D"auto">Note Hugs works hard at in= stance-processing/validation time (i.e. before it considers wanteds) to joi= n up instances to constraints to instances of the constraint class. It buil= ds a data structure around each instance decl, so the info is at its finger= tips for doing "multi-instance resolution".</div><div dir=3D"auto= "><br></div><div dir=3D"auto">AntC</div></div></div> --0000000000002b4b7f0576eca54d-- --===============7996805059168636910== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSHVncy1Vc2Vy cyBtYWlsaW5nIGxpc3QKSHVncy1Vc2Vyc0BoYXNrZWxsLm9yZwpodHRwOi8vbWFpbC5oYXNrZWxs Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vaHVncy11c2Vycwo= --===============7996805059168636910==--