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">&quot;

<span style=3D"color:rgb(64,64,64);font-family:Lato,proxima-nova,&quot;Helv=
etica Neue&quot;,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 &quot; says the User Guide. And the 2016 paper says likewise. But there=
&#39;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&#39;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&#39;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&#39;s Implement=
ation section 7 says the matcher also is an &quot;ordinary function&quot;.<=
/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&#39;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==--