OpTrex

--===============7545311488297181477==
Content-Type: multipart/alternative; boundary="000000000000d6cd690575ba0709"

--000000000000d6cd690575ba0709
Content-Type: text/plain; charset="UTF-8"

It's always seemed to me that field labels in records are more
constructor-like than term-like. And pattern-matching on them is more like
using them as (de-)constructors.

But H98 records create a selector function named for the field; and because
it's a function it must be term-like.

TRex field labels don't suffer this restriction: you don't get a selector
function; if you want a select by label from a TRex row, use the `#label
row` syntax.

Then I wondered: TRex labels appear only in a handful of syntax
productions. How hard would it be to allow them to look like constructors?
The answer is it's dead easy; you need only to change the syntax (in yacc
plus a tweak to the lexer); you don't need to change any of the code for
building/matching/typing rows. For now, I'm allowing labels to start either
upper or lower case.

Some example code here
https://github.com/ghc-proposals/ghc-proposals/pull/160#issuecomment-420272180

In particular, there's an example defining a Lens `bar` over any Trex row
containing a label `Bar`. (The main purpose of that definition is to
demonstrate every syntactic construct in which TRex allows labels, so it
could be terser.) Note that unlike Lenses over H98 style records, this
doesn't need an overloading for each different datatype containing a label
of some name.

My jazzy name for such Lense is 'OpTRex', as imagined here
https://github.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-414060490


AntC

--000000000000d6cd690575ba0709
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">It&#39;s always seemed to me that field labels in records=
 are more constructor-like than term-like. And pattern-matching on them is =
more like using them as (de-)constructors.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">But H98 records create a selector function named for the=
 field; and because it&#39;s a function it must be term-like.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">TRex field labels don&#39;t suffer th=
is restriction: you don&#39;t get a selector function; if you want a select=
 by label from a TRex row, use the `#label row` syntax.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">Then I wondered: TRex labels appear only in=
 a handful of syntax productions. How hard would it be to allow them to loo=
k like constructors? The answer is it&#39;s dead easy; you need only to cha=
nge the syntax (in yacc plus a tweak to the lexer); you don&#39;t need to c=
hange any of the code for building/matching/typing rows. For now, I&#39;m a=
llowing labels to start either upper or lower case.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Some example code here=C2=A0<div><a href=3D"htt=
ps://github.com/ghc-proposals/ghc-proposals/pull/160#issuecomment-420272180=
">https://github.com/ghc-proposals/ghc-proposals/pull/160#issuecomment-4202=
72180</a></div><div dir=3D"auto"><br></div><div dir=3D"auto">In particular,=
 there&#39;s an example defining a Lens `bar` over any Trex row containing =
a label `Bar`. (The main purpose of that definition is to demonstrate every=
 syntactic construct in which TRex allows labels, so it could be terser.) N=
ote that unlike Lenses over H98 style records, this doesn&#39;t need an ove=
rloading for each different datatype containing a label of some name.</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">My jazzy name for such Lense =
is &#39;OpTRex&#39;, as imagined here=C2=A0<div><a href=3D"https://github.c=
om/ghc-proposals/ghc-proposals/pull/158#issuecomment-414060490">https://git=
hub.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-414060490</a></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>AntC</div></div></div>

--000000000000d6cd690575ba0709--

--===============7545311488297181477==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSHVncy1Vc2Vy
cyBtYWlsaW5nIGxpc3QKSHVncy1Vc2Vyc0BoYXNrZWxsLm9yZwpodHRwOi8vbWFpbC5oYXNrZWxs
Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vaHVncy11c2Vycwo=

--===============7545311488297181477==--