Pattern Synonym decls only at top level
Anthony Clayden <[email protected]> Tue, 18 Apr 2023 16:45:51 +1200
| Newsgroups | gmane.comp.lang.haskell.glasgow.user |
|---|---|
| Message-ID | <CABU_mxgErm1btFU+app4FKZO6PAdf96GYcTiVZiuz2pu5CsrtQ@mail.gmail.com> |
--===============1831089476130257751== Content-Type: multipart/alternative; boundary="000000000000d9e8e605f994fbbf" --000000000000d9e8e605f994fbbf Content-Type: text/plain; charset="UTF-8" " Pattern synonym declarations can only occur in the top level of a module. In particular, they are not allowed as local definitions. " says the User Guide. And the 2016 paper says likewise. But there's no explanation why. PattSyns are not necessarily declared in the same module as the underlying Datatype, so there can be a region of scope with the data constructor but without the PattSyn. If PattSyns are declared in the same module as their datatype, you can export the PattSyns but not the data constructors -- indeed that's a common way to keep the Datatype implementation abstract. Or (unusually) you can export the data constructors but not PattSyns. So there seems to be no close tie-up of Datatype/constructors and PattSyns. Then why couldn't a PattSyn be declared in local scope only? The builder function behind a PattSyn is just like any other function, so could be local(?) The paper's Implementation section 7 says the matcher also is an "ordinary function". Relatedly, PattSyns can in effect be overloaded: define the PattSyn in terms of a ViewPattern function. That can be a method of some class. Then why not more directly declare PattSyns within a class? [I have a feeling I answered a similar question on some forum, saying the PattSyn has to follow around its data constructors, like a dog on a lead. Can't find that now. If that was me, I apologise and withdraw.] AntC --000000000000d9e8e605f994fbbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">" <span style=3D"color:rgb(64,64,64);font-family:Lato,proxima-nova,"Helv= etica Neue",Arial,sans-serif;font-size:16px;background-color:rgb(252,2= 52,252)">Pattern synonym declarations can only occur in the top level of a = module. In particular, they are not allowed as local definitions.</span>=C2= =A0 " says the User Guide. And the 2016 paper says likewise. But there= 's no explanation why.<div><br></div><div>PattSyns are not necessarily = declared in the same module as the underlying Datatype, so there can be a r= egion of scope with the data constructor but without the PattSyn.</div><div= ><br></div><div>If PattSyns are declared in the same module as their dataty= pe, you can export the PattSyns but not the data constructors -- indeed tha= t's a common way to keep the Datatype=C2=A0implementation abstract.</di= v><div><br></div><div>Or (unusually) you can export the data constructors b= ut not PattSyns. So there seems to be no close tie-up of Datatype/construct= ors and PattSyns. Then why couldn't a PattSyn be declared in local scop= e only?</div><div><br></div><div>The builder function behind a PattSyn is j= ust like any other function, so could be local(?) The paper's Implement= ation section 7 says the matcher also is an "ordinary function".<= /div><div><br></div><div>Relatedly, PattSyns can in effect be overloaded: d= efine the PattSyn in terms of a ViewPattern function. That can be a method = of some class. Then why not more directly declare PattSyns within a class?<= /div><div><br></div><div>[I have a feeling I answered a similar question on= some forum, saying the PattSyn has to follow around its data constructors,= like a dog on a lead. Can't find that now. If that was me, I apologise= and withdraw.]</div><div><br></div><div>AntC</div></div> --000000000000d9e8e605f994fbbf-- --===============1831089476130257751== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KR2xhc2dvdy1o YXNrZWxsLXVzZXJzIG1haWxpbmcgbGlzdApHbGFzZ293LWhhc2tlbGwtdXNlcnNAaGFza2VsbC5v cmcKaHR0cDovL21haWwuaGFza2VsbC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL2dsYXNn b3ctaGFza2VsbC11c2Vycwo= --===============1831089476130257751==--